By now you know how an LLM works, how to run one, how to make it useful and how to keep it safe. The last questions are the ones that decide whether a project gets approved and survives its first year. Are we allowed to do this with this data? Should we build it or buy it? And what will it really cost?

These questions get less attention than model benchmarks, but they sink more projects. This article gives you the durable principles and a way to reason about each one.

A note before we start: this article explains the general shape of the rules so you can ask the right questions. It is not legal advice. For a real system, talk to a lawyer or your data protection officer.

GDPR: personal data in prompts

The General Data Protection Regulation (GDPR) applies whenever you process personal data about people in the EU. Personal data is any information about an identifiable person: a name, an email address, an IP address, a customer ID that can be linked back to someone.

LLM systems process personal data more often than teams expect, because it hides inside ordinary text. Look at BUG-1423 again. The support tool that created it copied in the customer's message: "I can't log in as Maria@Example.com." That email address is personal data. It now sits in the ticket, in the prompt sent to the model, in the trace (Article 18), and possibly in the model provider's logs.

The diagram shows where that one email address travels during a single agent run.

flowchart TD
    A["Ticket with email"]:::io --> B["Agent harness"]:::infra
    B --> C["Gateway masks email"]:::infra
    C --> D["Model provider"]:::model
    B --> E["Traces and logs"]:::infra
    E --> F["Retention limit"]:::warn
    classDef model fill:#2a2140,stroke:#a78bfa,color:#ece5ff
    classDef infra fill:#12302d,stroke:#2dd4bf,color:#d5fbf5
    classDef io fill:#1f1d1a,stroke:#8a8275,color:#ece5d8
    classDef warn fill:#3a1d18,stroke:#fb7a5e,color:#ffe1d9

Figure 20.1: One customer email address, three destinations. Each place it lands needs a reason to be there and a limit on how long it stays.

The principles that matter most for LLM systems are durable and worth knowing by name:

  • Lawful basis. You need a legal reason to process personal data, such as performing a contract or a legitimate interest you have documented and balanced against the person's rights. Using support tickets to fix the bug the customer reported is easy to justify. Using the same tickets to fine-tune a model (Article 15) is a different purpose and needs its own assessment.
  • Data minimisation. Send only what the task needs. The agent needs to know the bug involves uppercase letters. It does not need Maria's real address. A gateway (Article 17) can replace it with a placeholder like <EMAIL_1> before the prompt leaves your network.
  • Processors and DPAs. When a model provider processes personal data on your behalf, it is a processor and you are the controller. GDPR requires a written data processing agreement (DPA) between you. Major providers offer one. Read what it says about whether your data is used for training and how long it is kept.
  • International transfers. If the provider processes data outside the EU, the transfer needs a legal mechanism, such as the European Commission's adequacy decisions or Standard Contractual Clauses. As of October 2026, transfers to certified US companies can still rely on the EU-US Data Privacy Framework. It survived a first court challenge in September 2025, but an appeal is pending at the EU's top court, and a June 2026 US Supreme Court ruling weakening the independence of the FTC, which enforces the framework, has led EU regulators to ask for a review. Many companies keep Standard Contractual Clauses ready as a fallback. Some providers offer EU data residency, which removes the question for the data stored there.
  • Retention. Decide how long prompts, outputs and traces are kept, and delete them on schedule. Debugging needs a few weeks of traces, not years.
  • Data subject rights. People can ask to see, correct or delete their data. If Maria asks, you must be able to find her email in your logs and traces. That is far easier if you masked it in the first place.

The EU AI Act

The EU AI Act is the first broad law regulating AI systems themselves rather than the data they use. It entered into force on 1 August 2024, with obligations that apply in stages.

The core idea is durable: rules scale with risk. The Act sorts AI uses into tiers.

  • Unacceptable risk: prohibited. A short list of practices is banned outright, such as social scoring of people and certain kinds of manipulation.
  • High risk: strict obligations. Uses in sensitive areas listed in the Act, such as hiring and managing employees, credit scoring, education and critical infrastructure. These require risk management, data governance, documentation, human oversight and more.
  • Limited risk: transparency. For example, people must be told when they are talking to an AI system, and some AI-generated content must be labelled.
  • Minimal risk: no new obligations. Most business uses fall here.

Separately, there are obligations for providers of general-purpose AI models, the large models themselves. These mostly fall on the companies that train the models, not on teams that call them through an API.

Where does our bug-fix agent sit? A tool that fixes code and opens pull requests for human review is most likely minimal risk. But the use, not the technology, decides the tier. If you started using the agent's data to rate your engineers' performance, that moves towards employment management, which is listed as high risk. The same model, used differently, falls under different rules. There is also an obligation, applying since February 2025, for organisations that deploy AI to take measures so their staff have sufficient AI literacy, which this series is one small way to address.

The diagram shows the staged dates as they stand after the 2026 amendment.

flowchart TD
    A["1 Aug 2024: in force"]:::io --> B["2 Feb 2025: bans, AI literacy"]:::io
    B --> C["2 Aug 2025: general-purpose models"]:::io
    C --> D["2 Aug 2026: transparency rules"]:::io
    D --> E["2 Dec 2027: high-risk uses"]:::warn
    E --> F["2 Aug 2028: high risk in products"]:::warn
    classDef model fill:#2a2140,stroke:#a78bfa,color:#ece5ff
    classDef infra fill:#12302d,stroke:#2dd4bf,color:#d5fbf5
    classDef io fill:#1f1d1a,stroke:#8a8275,color:#ece5d8
    classDef warn fill:#3a1d18,stroke:#fb7a5e,color:#ffe1d9

Figure 20.2: The AI Act's application dates after the Digital Omnibus amendment. The high-risk dates, in coral, were pushed back from 2026 and 2027.

The original 2024 text applied most high-risk rules from 2 August 2026. The European Commission proposed a delay in November 2025 as part of a "digital omnibus" package, and the EU adopted it in mid-2026. Stand-alone high-risk uses, such as hiring, credit scoring and education, now apply from 2 December 2027, and high-risk AI built into regulated products from 2 August 2028. Transparency obligations, such as telling people they are talking to an AI system, still applied from 2 August 2026. Dates like these have moved once and could move again, so check the official text before you rely on them. Penalties under the Act scale with the breach and reach up to €35 million or 7% of worldwide annual turnover, whichever is higher, for prohibited practices.

Build versus buy

For a capability like our bug-fix agent, there are roughly three options:

  • Buy a product. Use an existing coding agent as a service. Fastest to start, least control. You depend on the vendor's roadmap, data handling and pricing.
  • Build on a model API. Write your own harness, tools, evals and gateway, and call a hosted model. More work, much more control over workflow, data and integration with your systems.
  • Self-host an open-weight model. Build as above, but run the model yourself (Articles 11 and 12). The most control over data, and the most operational work.

A useful rule: buy what is generic, build what is specific to you. Code review assistance is generic and well served by products. An agent that knows your deployment process, your internal tools and your compliance rules may be worth building. And you can start by buying, learn what you actually need, then build the parts the product can't do.

A worked example: total cost of ownership

The token bill is the number everyone looks at, and it is usually the smallest part of the cost. Let's work it through. Every figure below is illustrative, chosen to show the method, not taken from any vendor's price list or any real team.

Assumptions. The agent handles 300 tickets a month. An average run uses 150,000 input tokens and 8,000 output tokens. The model costs $3 per million input tokens and $15 per million output tokens.

Step 1: tokens per run.

  • Input: 150,000 ÷ 1,000,000 × $3 = $0.45
  • Output: 8,000 ÷ 1,000,000 × $15 = $0.12
  • Per run: $0.45 + $0.12 = $0.57

Step 2: tokens per month. 300 runs × $0.57 = $171. Agents retry and some runs fail and get re-run, so add 30%: $171 × 1.3 = $222.30.

Step 3: everything else per month.

  • Infrastructure (sandboxes, gateway, tracing): $400.
  • Maintenance (prompt updates, evals, model upgrades), a quarter of one engineer at $10,000 a month: 0.25 × $10,000 = $2,500.
  • Human review: 15 minutes per pull request, at $60 an hour. 300 × 0.25 hours = 75 hours, and 75 × $60 = $4,500.

Monthly running cost: $222.30 + $400 + $2,500 + $4,500 = $7,622.30.

The chart shows how that monthly cost splits up.

Illustrative monthly cost, $ Review 4,500 Maintenance 2,500 Infra 400 Tokens 222

Figure 20.3: In this illustrative model, the model's token bill is about 3% of the monthly cost. People's time is most of it.

The token share is $222.30 ÷ $7,622.30 ≈ 0.029, about 3%. Halving the token price saves about $111 a month. Cutting review time from 15 minutes to 10 saves $1,500. That is where the money is.

Step 4: first-year cost of building. Add a one-off build of two engineers for three months: 6 × $10,000 = $60,000. Year one: $60,000 + 12 × $7,622.30 = $60,000 + $91,467.60 = $151,467.60.

Step 5: compare with buying. Suppose a product costs $40 per developer per month for 25 developers, which is $1,000 a month, plus one engineer-month of integration, $10,000. Review time doesn't disappear, so keep the $4,500. Year one: $10,000 + 12 × ($1,000 + $4,500) = $10,000 + $66,000 = $76,000.

With these made-up numbers, buying is about half the cost in year one. Building wins only if it does something the product can't, if usage grows enough to change the maths, or if data rules leave you no choice. Run the same calculation with your own figures. The method is the useful part, not these numbers.

Where this shows up in our bug-fix agent

Before the agent touches its first real ticket, someone has to answer the questions in this article:

  • GDPR: tickets contain customer emails. The gateway masks them, the provider has a signed DPA, traces are kept for 30 days, and you know where data is processed.
  • AI Act: the agent fixes code under human review, which most likely puts it in the minimal-risk tier. Its data is not used to evaluate engineers, which would change that. Staff using it have had basic training.
  • Build or buy: you start with a product to learn, and build your own harness only when you need deeper integration with your deployment and review process.
  • Cost: you track cost per ticket from the traces (Article 18), but you manage review time, because that is most of the bill.

Common misconceptions

"We use a big provider, so compliance is their problem." The provider is your processor, but you remain the controller. You decide what data goes in, for what purpose and for how long, and you answer to the people it belongs to.

"The AI Act applies to the AI companies, not to us." Some obligations fall on model providers, but the risk tier depends on how you use AI. A company using an off-the-shelf model for hiring decisions takes on high-risk obligations itself.

"Cheaper tokens mean a cheaper system." Tokens are often a small share of the total. People's time for building, maintaining and reviewing usually dominates.

"Building always gives you an edge." Building something generic that you could buy mostly gives you something to maintain. Build where your process is genuinely different.

Key takeaways

  • Personal data hides in ordinary text, such as tickets and logs. Minimise it, mask it at the gateway, sign a DPA, and set retention limits.
  • The EU AI Act regulates by use and risk tier. The same model can be minimal risk in one use and high risk in another. Check current dates before relying on them.
  • Buy what is generic, build what is specific to your organisation, and it's fine to start by buying.
  • Work out total cost of ownership with your own numbers. The token bill is rarely the biggest line.
  • None of this replaces legal advice for your actual system.

Glossary

  • GDPR: the EU's General Data Protection Regulation, which governs how personal data about people in the EU is processed.
  • Personal data: any information about an identifiable person, such as a name or email address.
  • Controller: the organisation that decides why and how personal data is processed.
  • Processor: an organisation that processes personal data on a controller's behalf, such as a model provider.
  • DPA (data processing agreement): the contract GDPR requires between a controller and a processor.
  • Data minimisation: the principle of processing only the personal data a purpose actually needs.
  • Data residency: where data is physically stored and processed, for example only in EU data centres.
  • EU AI Act: the EU regulation that sets rules for AI systems according to their risk.
  • High-risk AI system: a use of AI in an area the Act lists as sensitive, such as hiring, which carries strict obligations.
  • General-purpose AI model: a model trained for a wide range of tasks, whose providers have their own obligations under the Act.
  • Total cost of ownership (TCO): the full cost of a system over time, including people, infrastructure and maintenance, not just the purchase or usage price.

Wrapping up the series

That's the end of The World of AI. We started with a machine that predicts the next token and finished with the laws, budgets and decisions around a production system.

Along the way, one agent fixed one bug. You have seen BUG-1423 broken into tokens and embeddings, pushed through attention layers on a GPU, retrieved, prompted, routed through a gateway, traced, attacked, sandboxed, and costed. The point of following one example was that each piece connects to the others. When something goes wrong in a real AI system, the cause is usually at one of those joins.

If you want to revisit any part, the full list is on the series page. And if you build something with what you learned here, or spot something I got wrong, I'd like to hear about it.