AI Risks: A Practical Guide for Builders

AI risks are easier to manage when you stop sorting them by category and start sorting them by who gets hurt. Most risk guides list bias, hallucination, privacy, security and regulation as five equal boxes. That framing is tidy and close to useless when you have a product to ship, because it does not tell you what to fix first. The question that does is simpler: if this goes wrong, who carries it?

Three answers, and each one has a different control.

You carry it. Your users carry it. Your client or employer carries it. Sort a risk into the right bucket and the mitigation usually becomes obvious, because the person holding the consequence is the person you have to be able to face afterwards.

This guide walks all three. It is written for people building with AI rather than for a compliance committee, so the controls are things you can do this week, not governance frameworks you need a department to run.

Risks you carry yourself

These are the ones where a mistake costs you money, time or credibility, and nobody else finds out unless you tell them. They are the cheapest to fix and the most commonly ignored, precisely because there is no external pressure.

Code you shipped and never read

The single most common self-inflicted wound. A model produces something plausible, it runs, you ship it. Weeks later you discover it never handled the empty case, or it wrote to the wrong table, or it silently retried a payment.

The failure mode is not that models write bad code. It is that they write *confident* code. There is no visible difference between a function the model reasoned through and one it pattern-matched from something similar. Both compile. Both look like they were written by someone who knew what they were doing.

The control is a review habit, not a tool. How to review AI generated code before you ship it covers the specific checks, and why AI writes code that doesn't work explains the underlying reason so you know where to look hardest.

Building on an assumption the model invented

Models produce fluent, well-structured, wrong statements about APIs, pricing, limits and behaviour. This is hallucination, and in a build context it is expensive rather than embarrassing: you design around a capability that does not exist, and you find out three days in.

The control is a rule about categories, not a request for accuracy. Anything a model tells you about a *specific external system* gets checked against that system's own documentation before you build on it. Rate limits, pricing tiers, field names, webhook payloads, which parameters are required. Not because the model is usually wrong, but because you cannot tell the difference from the inside, and the cost of checking is two minutes.

Cost that scales differently than you expect

Token costs are small per call and non-linear in aggregate. The pattern that catches people: a feature works fine in testing at 40 calls a day and becomes the largest line on the bill when a retry loop, a longer context, or actual traffic arrives. Long context windows make this sharper, because the same feature can cost ten times more per call depending on how much history it drags along.

The control is a hard spend cap at the provider, set before launch, plus logging of tokens per request so you can see the shape of usage rather than the total.

Lock-in you did not choose

You built on one provider's API, their tool-calling format, their embedding dimensions and their fine-tuning pipeline. Then they deprecate a model, or change pricing, or your use case bumps into a policy.

The control is not avoiding providers. It is keeping the boundary thin: your application talks to a small internal interface, and the provider-specific code lives behind it. Open-weight versus closed AI models covers when self-hosting is a real alternative rather than a theoretical one.

Behaviour that changes underneath you

The least discussed operational risk in this whole list. You built a feature, tuned the prompt until the output was reliably correct, and shipped it. Then the provider updates the model behind the same version string, or you get silently moved to a successor, and the output shifts. Not dramatically. Slightly. Formatting drifts, a section you relied on stops appearing, an edge case that used to be handled starts producing something odd.

Nothing errored. Your monitoring is green. The feature is quietly worse and nobody knows for how long.

This is different from a deprecation, which is announced and forces a decision. This is drift, and it is invisible by design because the interface did not change.

Two controls, and the first one costs almost nothing:

• Pin the model version explicitly wherever the provider allows it, rather than using an alias that tracks the latest. Aliases are convenient right up to the morning they are not.

• Keep a small regression set. Ten to twenty real inputs with known-good outputs, run on a schedule, compared automatically. It does not need to be sophisticated. It needs to exist, because it is the only thing that turns a silent quality change into a visible one.

The regression set is also what makes model upgrades safe rather than frightening. Without one, every version change is a gamble you take blind; with one, it is a test you run in ten minutes.

Risks your users carry

Now the stakes change. A mistake here lands on someone who trusted your product and had no way to inspect it. These deserve more of your attention than the first group, and usually get less.

Their data going somewhere they did not agree to

If your app sends user content to a model provider, that is a disclosure. Whether it is an acceptable one depends on what you told them, what the provider's terms say about training on it, and what category of data it is. Health information, financial records and anything about children raise the bar considerably. Inbox access sits in the same high-sensitivity category, since letting AI read your email can expose all three at once.

The controls, in order of how much they buy you:

1. Send less. Most features need a fragment, not the whole record. Strip identifiers before the call. A summarisation feature rarely needs the customer's name and never needs their account number.

2. Use the API tier, not the consumer product. Business and API tiers generally carry different data-retention and training terms than consumer chat interfaces. Read the actual terms for the specific product you are calling.

3. Say so plainly. One clear sentence in your privacy policy naming which provider processes what. Users who care will look, and regulators certainly will.

Is it safe to give AI access to my data goes into this in more depth, including the retrieval-instead-of-upload pattern that keeps documents in your own storage.

Prompt injection turning your feature against them

This is the one that most teams have not internalised. If your application feeds any untrusted text into a model that can then take actions, that text can carry instructions. A support ticket, a scraped page, a PDF a user uploaded, an email body. The model does not reliably distinguish "content to process" from "instructions to follow", because at the level it operates, both are just text in the context.

The consequences are concrete: data from one user's session leaking into another's response, an agent making an API call it was talked into, a summariser that follows a hidden instruction to omit something.

What is prompt injection covers the mechanics. The architectural control is the important part, and it is a design decision rather than a filter: never give a model that reads untrusted input the ability to take a consequential action without a check outside the model. Retrieval is fine. Sending an email, moving money, or writing to a database is not, unless something deterministic validates it first. OWASP's Top 10 for LLM applications is the reference worth reading properly here.

Being misled by output that looks authoritative

Your interface makes a claim about how much to trust what it shows. A clean, confident, well-formatted answer reads as verified whether or not anything verified it. If your product tells someone their tax situation, their symptoms or their legal position, the design choice about how you present uncertainty is a safety decision.

The control is showing the seams. Cite the source your answer came from, distinguish retrieved facts from generated prose, and let people see the underlying record. This costs some polish and buys back a great deal.

Fraud that uses your product's shape

Generated text, voices and images have made a class of scam much cheaper to run. Your users may encounter it through your product, or impersonating your product. Knowing what current attacks look like is part of protecting them: how to spot an AI scam and how to tell if a photo is AI generated both cover the practical tells.

Risks your client or employer carries

If you are building for someone else, a third bucket opens: risks that land on the organisation you are working for, often after you have moved on.

Ownership that was never established

Code, copy and images produced with substantial model involvement sit in a genuinely unsettled area of copyright, and it varies by jurisdiction. If a client assumes they own everything you deliver, and the enforceability of that is uncertain, the problem surfaces at acquisition or litigation, not at handover.

The control is a conversation and a clause, not a legal opinion you are not qualified to give. Who owns AI generated code lays out the current position.

Regulatory exposure they did not know they had

The EU AI Act is the one with teeth and a timetable. What matters is that obligations attach to *use cases*, not to whether you consider yourself an AI company. A hiring filter, a credit decision, an education assessment tool: these pick up requirements that a chatbot for restaurant bookings does not.

If you are building for a European client, or one with European users, the classification question needs answering at design time, because retrofitting documentation, human oversight and logging into a shipped system is far more expensive than designing for it. We cover the specifics in EU AI Act transparency rules and the high-risk deadline, and the official EU AI Act resource is the primary reference.

A system nobody can maintain

The quiet one. You deliver something that works, built quickly with heavy model assistance, and it is understood by nobody, including you. Six months later the client needs a change and the only viable path is a rewrite.

The control is documentation written at handover, while the reasoning is still in your head: what the system does, what it assumes, which parts were generated and lightly reviewed, and where the known soft spots are. This also happens to be the honest thing to do.

Risks that get less attention than they deserve, and more

Worth being direct about the imbalance, because attention spent on the wrong risks is attention not spent on the right ones.

Underrated: the boring operational ones. Silent model drift, cost that scales unexpectedly, a system nobody can maintain, and unreviewed code. These are unglamorous, they account for most of what actually goes wrong in small teams, and they are all cheap to control. None of them will appear in a conference talk.

Underrated: prompt injection. Genuinely the most serious technical risk for anyone building an agent, and still treated by many teams as a curiosity rather than an architectural constraint. The gap between how seriously security researchers take this and how seriously product teams take it is the widest in this list.

Overrated for most builders: model bias as an abstract concern. Not because bias is not real, it demonstrably is, but because the framing is usually too abstract to act on. "The model may reflect societal biases" does not tell you what to do on Tuesday. The actionable version is narrow and specific: if your system makes or influences a decision *about a person*, ranking candidates, scoring applications, prioritising cases, then you need to test outcomes across groups and you probably have regulatory obligations too. If it drafts product descriptions, this concern does not apply in any operational sense, and treating it as though it does is how risk processes lose credibility.

Overrated: existential and long-horizon scenarios. These may matter enormously at the level of national policy. They have no bearing on whether your booking app leaks customer data next month. Keeping the two conversations separate is what lets you take both seriously.

The pattern: the risks that get airtime are the ones that are interesting to discuss, and the risks that cost people money are the ones that are tedious to fix. Spend your attention accordingly.

A short triage you can actually run

Before shipping anything with a model in it, four questions:

1. If this produces a wrong answer, who finds out and when? If the answer is "the user, and never", you need visible sourcing.

2. Can untrusted text reach the model? If yes, assume it carries instructions, and make sure the model cannot take a consequential action on its own.

3. What data leaves, and did anyone agree to that? Reduce the payload first, then check the provider terms, then write it down.

4. What breaks if the provider changes something next month? Price, deprecation, policy. If the answer is "everything", thin the boundary.

Four questions is a deliberately short list. A risk process nobody runs protects nothing, and most real incidents trace back to one of these four rather than to anything exotic. For organisations that need something more formal, NIST's AI Risk Management Framework is the structured version.

FAQ

What is the biggest risk of using AI in a product?

For most small teams it is prompt injection combined with an agent that can take actions, because it converts a text-handling bug into unauthorised behaviour. For solo builders it is usually shipping unreviewed generated code.

Do I need to worry about the EU AI Act if I am not in Europe?

If you have European users, generally yes. Obligations follow the use case and the market, not where your company is registered. Whether they are significant depends on how your system is classified.

Is it safe to put customer data into an AI tool?

It depends on the tool's terms, the category of data, and what you told your customers. The reliable move is to send the minimum fragment needed rather than the full record, and to use business or API tiers whose retention terms you have actually read.

How do I stop a model from making things up?

You do not stop it, you contain it. Ground answers in retrieved sources, show those sources to the user, and verify anything the model asserts about an external system against that system's own documentation before you build on it.

Are AI risks a reason not to build with AI?

No. They are a reason to know which bucket each risk falls into. Almost every serious failure in this guide traces back to one decision: giving a model more authority than the surrounding system can check.