In the previous lesson we learned to audit our own models: bias, explainability, privacy, synthetic content. But the TecnoMarket team does not operate in a vacuum. Every model it deploys takes part in a much larger transformation: deep learning is changing which jobs exist, who can afford this technology, how entire sectors work, and how much energy the digital industry consumes. This lesson zooms out: from the individual model to society and the economy. Not to philosophize in the abstract, but because a deep learning professional makes better decisions — and performs better in an interview, on a steering committee, or in front of a journalist — when they understand the context they work in.

1. The transformation of employment: tasks, not jobs
2. The TecnoMarket case: what its models automate and what they create
3. Reskilling: the sensible response
4. Concentration vs. democratization of deep learning
5. Impact by sector: benefits and risks
6. The digital divide and unequal access
7. The environmental cost of deep learning
8. The individual professional's responsibility

The public debate is usually framed badly: "will AI destroy X million jobs?". The framework economists use is more useful: automation operates on tasks, not on jobs. A job is a bundle of tasks; deep learning automates some of them — usually the repetitive and perceptual ones — and leaves the rest. This produces three distinct scenarios:

• Augmentation: the model does the mechanical part and the person does more of everything else (judgment, personal contact, exceptions). The job changes; it does not disappear. This is the most common scenario.
• Partial substitution: if the model automates most of a job's tasks, fewer people are needed for the same volume. The job does not disappear, but it shrinks.
• Complete substitution: rare in practice; it happens when the job was essentially a single automatable task.

At the same time, automation creates new tasks that did not exist before: preparing data, labeling, supervising models, reviewing their outputs, maintaining the infrastructure. The history of technology repeats this pattern (ATMs reduced teller tasks, yet banks opened more branches with employees doing other things); what nobody guarantees is that the people displaced from the old tasks will be the same ones who fill the new ones, or that the transition will be painless. That is where the real problem lies: not in the net job balance, but in the transition and in who pays for it.

Let's apply the task-by-task framework to our own portfolio. This table is the exercise any company should do before talking about "headcount savings":

Three honest observations about the table:

1. No TecnoMarket job disappears entirely, but several shrink: if the generator drafts 80% of the copy, perhaps 2 copywriters are needed where there were 4.
2. The new roles are not symmetrical to the old ones: "data labeler" is usually paid worse than "copywriter"; "ML engineer", better. Automation tends to polarize: the highly skilled and the low skilled grow, and the middle narrows.
3. The human review queue is not a leftover: it is a new role with judgment of its own (03-04, 07-02, 07-03). Designing it well — reasonable volume, tools, the ability to correct the model — is job design, not just software design.

If the problem is the transition, the main tool is reskilling, along with its smaller cousin, upskilling (going deeper in one's own role with new tools). What we know about what works:

• Reskill from domain knowledge: the best reviewer for the fraud queue is someone from the anti-fraud team, not a newcomer. Business knowledge does not get automated; the new roles should be built on top of it.
• Training with real practice, not just courses: labeling real data, reviewing real model outputs. (This course has followed that philosophy: every concept landed in a project.)
• Anticipation: reskill people before deploying the model that changes their job, not after. At TecnoMarket, the copywriters should be training as AI-content editors while the 07-02 generator is still in testing.
• Shared responsibility: companies (training their workforce instead of churning through people), governments (public training, safety nets) and individuals (accepting that continuous learning is no longer optional in technical careers... as proven by the fact that you are taking this course).

There is a central economic tension in the field, and TecnoMarket has lived it first-hand:

Forces of concentration. Training a frontier foundation model (the LLMs of 05-05) costs tens or hundreds of millions of euros in compute, plus internet-scale data and extremely scarce talent. Only a handful of big tech companies and labs can afford that. Whoever controls the best models, the chips and the cloud captures a growing share of the value: a risk of technological oligopoly.

Forces of democratization. At the same time, it has never been cheaper to use first-rate deep learning:

• Transfer learning (05-03): TecnoMarket beat its own CNN with a fine-tuned MobileNetV2 (07-05, ~91% versus ~82-85%) in an afternoon and on a modest GPU. It did not train from scratch: it stood on the shoulders of a model pretrained by others.
• Open models and weights: architectures, pretrained weights and libraries (TensorFlow, PyTorch, module 6) published for free.
• APIs: accessing a frontier LLM costs cents per query, with no infrastructure of your own.
• Open education: the field's knowledge is in papers, courses and public documentation.

The honest synthesis: usage is democratizing; the creation of frontier models is concentrating. A small team like TecnoMarket's can build excellent products (we have proven it over seven modules), but it depends structurally on base models, clouds and tools produced by a few actors. That dependence is a strategic decision companies must make with eyes open: what happens to my product if the model provider raises prices, changes terms or discontinues the API?

Deep learning does not hit everywhere equally. A panorama of four sectors, with the honesty of putting risks next to benefits:

The cross-cutting pattern: the benefits are about scale and access (bringing expensive capabilities to more people) and the risks are about quality, fairness and power (who suffers the errors, who is left out, who controls the tool).

The transformation above is not evenly distributed:

• Between countries: research, chips and data centers concentrate in a few regions; many countries participate only as consumers of the technology (and sometimes as providers of cheap labeling: a large share of the world's data labeling is done in low-income countries under questionable working conditions — the "magical" datasets of this course were labeled by people).
• Between companies: a large platform has data, talent and infrastructure; the small neighborhood shop competes against TecnoMarket's personalization with no way to replicate it.
• Between people: access to education (English, connectivity, time) determines who fills the well-paid new roles from the earlier table. Models, moreover, work better in the majority languages and cultures of their data: an LLM understands minoritized languages worse, reinforcing the advantage of those who already had it.

For the professional, the practical implication is twofold: be aware of who your product leaves out (does the AI-powered TecnoMarket site work for elderly customers, on poor bandwidth, in other languages?) and appreciate the genuinely democratizing effect of the open tools you yourself use.

Training and serving models consumes energy, and it pays to handle honest orders of magnitude rather than alarmist headlines or denialism:

• Training: training a large foundation model consumes on the order of gigawatt-hours — comparable to the annual consumption of hundreds or thousands of homes — and happens rarely. Training TecnoMarket's models (hours on one GPU) consumes about what a house uses in a day or two: scale is everything.
• Inference: this is the silent cost. A single query consumes little (on the order of thousandths of a kWh for large models), but multiplied by billions of daily queries, aggregate inference exceeds training in the sector's total. For TecnoMarket: the classifier is trained once a month, but it classifies photos all day, every day.
• The context: data centers (all of them, not just AI) account for a fraction of a few percentage points of the world's electricity, with AI as the fastest-growing component. Neither "AI is going to melt the planet" nor "it's negligible": it is a real, growing and manageable cost.

The good news is that efficiency is already a dominant technical trend, and the course has practiced it without naming it:

• Efficient architectures: we chose MobileNetV2 in 07-05 precisely because it is designed to do more with less compute.
• Transfer learning (05-03): reusing an existing pretraining avoids repeating its energy cost thousands of times.
• Quantization and compression (mentioned in 06-05 at deployment time): weights in fewer bits ⇒ less energy per inference.
• Operational decisions: don't retrain without need (let the drift monitoring of 06-05 decide, not the calendar), size the model to the problem (the 04-04 baseline is sometimes enough), and choose cloud providers running on renewable energy.

What can a single person do in the face of forces at this scale? More than it seems, because macro decisions are executed through micro decisions that someone like you makes every week:

• Choose a model proportional to the problem (does this really need a giant model?): an economic, environmental and maintainability decision all at once.
• Design the human roles with dignity: a well-designed review queue (humane volume, tools, the authority to correct the model) is a design decision of yours, not an HR matter.
• Do the task-by-task table before promising savings: it gives management a realistic picture of what gets automated and which new roles must be created and trained.
• Document dependencies: which base models, APIs and clouds hold the product up, and what plan B exists.
• Report honestly: neither selling magic ("AI will solve it") nor sowing panic; the numbers in this lesson are a good antidote to both.
• Use your position: technical professionals are scarce; that gives you real leverage to refuse to build what fails the 08-01 checklist and to escalate this lesson's problems to whoever decides.

• Thinking in "destroyed jobs" instead of "transformed tasks". It leads to paralysis or to false promises. TecnoMarket's task-by-task table is the right exercise, and you can replicate it in any organization.
• Ignoring the new roles when calculating the "savings". The cost of labeling, human review and model maintenance (more on this in 08-04) greatly reduces the apparent net savings. Presenting only half the equation ends in failed projects and unjustified layoffs.
• Confusing "using cheap AI" with "depending on no one". Transfer learning and APIs democratize usage, but they create structural dependence on the provider. Always document the plan B.
• Quoting environmental figures without distinguishing training from inference. They are different regimes: training is one-off and enormous; inference is tiny and constant. In a production product, inference usually dominates.
• Tip: when asked for your opinion on "the impact of AI", always come down to a concrete case (one job, one sector, one model). Abstract discussions cannot be resolved; concrete ones can.
• Tip: keep the sector table and the task-by-task table as templates. They are among the few artifacts in this lesson that are directly reusable in a boardroom.

TecnoMarket's management proposes: "with the description generator and the classifier, we can shrink the catalog team from 6 to 2 people and save €160,000/year". They ask you for a report. Using the task-by-task framework and the portfolio table: (a) break the catalog team's work down into tasks and classify them (automated / augmented / not automatable); (b) identify the new costs the proposal omits; (c) formulate a realistic counterproposal with headcount and roles.

TecnoMarket is considering replacing its in-house description generator (07-02) with a commercial LLM API: far superior quality, a cost of ~€0.002 per description, zero in-house maintenance. Analyze the decision with this lesson's frameworks: benefits, concentration/dependence risks, impact on internal roles, and relative environmental cost. What conditions would you set before approving the change?

The team debates two retraining policies for the photo classifier: (A) retrain every night "to always be up to date"; (B) retrain only when the drift monitoring from 06-05 crosses a threshold, with a quarterly minimum. Compare both in energy/economic cost, risk of model degradation and team workload, and choose with justification.

Solution 1. (a) Typical catalog-team tasks: categorizing photos (automated by 07-05, with a review queue for doubtful cases), writing descriptions (augmented: the 07-02 generator drafts, the person edits and fact-checks — review is mandatory under our own policy), verifying the accuracy of product pages (not automatable: the generator can invent features), managing the category taxonomy (not automatable), assisting sellers with misclassified products (not automatable), overall quality control (augmented). (b) Omitted costs: reviewers for the human queue (the homemade-photo volume from 08-01 fills it), periodic labeling for retraining, editing of every generated draft, maintenance and auditing of both models, and the transition cost (training). In addition, the reputational risk of publishing invented, unreviewed descriptions has a non-zero expected cost. (c) A reasonable counterproposal: from 6 to 4 people, with redefined roles: 2 AI-content editor-reviewers (former copywriters, trained before the rollout), 1 taxonomy and quality lead who also audits bias by subgroup (08-01), 1 seller manager handling the queue's cases. Smaller savings than promised (~€80,000/year) but sustainable, with no risk of an invented catalog and with the transition paid for through internal reskilling, not through layoffs and external hires.

Solution 2. Benefits: immediate superior quality, zero maintenance of the in-house model, extremely low marginal cost (at €0.002, even 1 million descriptions/year is €2,000, well below the cost of maintaining the in-house model). Dependence risks: the provider can raise prices, change terms, degrade the model or discontinue it; the descriptions (product data, perhaps customer data in the prompts) go to a third party — review with legal (08-01, point 9 of the checklist); a dependence that is hard to reverse once the internal know-how has been dismantled. Internal roles: the editor-reviewer is still needed (the LLM invents too); the team's ML knowledge atrophies if everything is outsourced — keep the in-house model as a documented fallback. Environmental: inference on a large LLM consumes more per query than the small in-house model, but the in-house retraining is avoided; at this volume, the difference is minor compared to the other factors. Reasonable conditions: a contract with price and version guarantees; a ban on sending personal data in the prompts; keep the in-house generator as plan B; human review untouched; comparative metrics (quality and cost) evaluated at 3 months on a frozen set, as in 06-05.

Solution 3. Policy A: an energy and economic cost of ~90 retrainings/quarter versus ~1-3 for policy B (two orders of magnitude more), with no proportional benefit: catalog data does not change that fast, and each retraining introduces regression risk (you must revalidate on the frozen set and re-audit bias by subgroup every time, 08-01 — with daily retraining, that audit will get skipped in practice, which is the real danger). Policy B: aligns the spend with the actual measured need (the drift signal from 06-05 is designed exactly for this), keeps the audits viable, and leaves the quarterly minimum as a safety net against slow drifts the threshold might miss. Choice: B, with one improvement: review the drift threshold after the first quarter. The general lesson: "always up to date" sounds rigorous but here it is a waste of energy and team effort with no measurable gain; real rigor is retraining when the data asks for it.

We have placed TecnoMarket's work in its real context: automation operates task by task — and the portfolio table shows it creates reviewers, labelers and engineers even as it shrinks other roles —, the sensible response to the transition is anticipated reskilling, the field lives the tension between concentration (creating frontier models) and democratization (using them, as we did with transfer learning in 05-03/07-05), every sector receives benefits of scale alongside risks of fairness, the digital divide decides who gets to participate, and the environmental cost is real but manageable with the efficiency we already practice. And above all: macro forces are executed through micro decisions made by people like you. With the ethical dimension (08-01) and the social one (this lesson) covered, it is time to look ahead: where is deep learning heading technically, and what do those trends mean for a team like TecnoMarket's? That is the topic of the next lesson: the field's future trends.