Shipping an AI feature? Start with a system map.

When a team ships an AI feature, the first question is often “which model are we using?” It is the wrong place to start a legal review. The same model can power a harmless drafting assistant and a tool that decides who gets a job interview. The law treats those two very differently.

What drives legal exposure is what the system does, who relies on it, who it affects and whether anyone can challenge the result. That is true under the EU AI Act, under US state laws on automated decisions, under the UK’s data protection rules and under the new AI laws in Asia.

The practical answer is a system map: a one-page description of each AI feature that legal, product and engineering can all read. This article explains what goes on it, how regulators in different markets will read it, and how to turn it into product decisions.

Why the model name tells you little

A model is a component. Legal obligations usually attach to the system you build around it and to the purpose you use it for. An internal tool that summarises meeting notes and a customer-facing tool that scores loan applicants may call the same API, but only one is likely to be treated as high-risk.

That is why a model card or vendor certification, on its own, rarely answers your compliance questions. You still need to describe your own use case, because that is what regulators, customers and courts will look at.

What goes on a system map

Keep it to one page per feature. The aim is a shared description that lets a lawyer spot the issues in minutes, and lets the product team see why a question matters. Update it whenever the feature changes.

Plain language matters more than completeness. “Ranks inbound CVs and hides the bottom half from recruiters” tells a reviewer far more than “AI-assisted talent workflow optimisation”.

Purpose: what the feature is for, in one sentence
Users: who operates it, internal staff or customers
Affected people: whose interests the output touches
Decision: what the output influences, and how much weight it carries
Model and vendors: which models, APIs and data providers sit underneath
Data: what goes in, including personal data, and what comes out
Oversight: who can review, override or challenge an output
Markets: where the feature is offered and where its outputs are used
Owner: the named person accountable for the feature

Describe the decision, not just the model

The most important line on the map is the decision. Many laws focus on AI used for consequential decisions about people, such as hiring, lending, insurance, housing, education and access to essential services. If your feature influences one of these, expect heavier duties.

In the EU, AI used in these areas is generally listed as high-risk in Annex III of the AI Act. After the 2026 Digital Omnibus amendments, those obligations apply from 2 December 2027. In the US, California’s rules on automated decision-making technology apply from 1 January 2027, Colorado’s rewritten AI law is due to take effect on the same date although its enforcement is currently stayed, and New York City already requires bias audits for automated hiring tools. In the UK, the Data (Use and Access) Act 2025 reshaped the rules on automated decisions with safeguards such as the right to human intervention.

The detail differs, but the common threads are notice, explanation, human review and records. Design those into the feature once, and you can adapt them per market.

Identify your role and your supply chain

Building, integrating and deploying AI are different activities. Under the EU AI Act, a “provider” develops an AI system or model and places it on the market under its own name. A “deployer” uses an AI system in its own activities. Providers carry most of the obligations, but deployers have duties too.

Roles can shift. If you put your own name or trademark on a high-risk system, substantially modify it or change its purpose so that it becomes high-risk, you can be treated as its provider. Contract labels alone do not settle regulatory roles.

Map each link in the chain: model provider, your application, your customer and the end user. Then check the contracts against the map.

Can the vendor retain your inputs, or use them to train its models?
Will the vendor notify you before changing or retiring the model?
Who handles incidents, and how fast must each party report?
Do licence terms restrict your intended use or market?
What documentation will the vendor give you to meet your own duties?

Transparency duties are live now

You do not need a high-risk system to have obligations today. Since 2 August 2026, the EU AI Act’s Article 50 requires that people are told when they interact with an AI system, and that deepfakes and certain AI-generated text are disclosed. Machine-readable marking duties for generative systems already on the market before August 2026 follow on 2 December 2026.

Asia is moving in the same direction. South Korea’s AI Basic Act, in force since 22 January 2026, brings notice and labelling for generative AI and, for some foreign providers, a local representative. China has required visible labels and embedded metadata for AI-generated content since 1 September 2025. India’s amended IT Rules, in force since February 2026, bring labelling for synthetic content on platforms.

If your feature chats with users or produces images, audio, video or text that could be mistaken for human work, put disclosure and labelling on the system map now.

Treat risk as a lifecycle question

The NIST AI Risk Management Framework, published in the US in 2023, organises AI risk work around four functions: Govern, Map, Measure and Manage. It is voluntary and is not a compliance certificate. Its value is in the questions it makes you ask: does someone own the risk, do you understand the context, can you evaluate outcomes and can you respond when something changes? NIST has also published a companion profile for generative AI.

ISO/IEC 42001, also from 2023, is a certifiable standard for an AI management system. Enterprise buyers increasingly ask for one or the other, and some laws, such as Texas’s TRAIGA, link safe harbours to recognised frameworks. Singapore’s AI Verify testing toolkit is another useful reference for Asia-facing teams.

None of these frameworks replaces the law. Use them as the backbone of a governance process that can travel across jurisdictions, then add each market’s specific duties on top.

Turn findings into product decisions

A system map is only useful if it changes what you build. For each feature, decide which uses are permitted, when sign-off is needed before launch and which outputs need a human in the loop. Decide what gets logged and for how long, and who reviews incidents.

Then build the evidence as you go. Test results, model versions, change logs and user notices are much easier to keep from day one than to reconstruct during a customer audit or a regulator’s inquiry. For EU-facing high-risk systems, this documentation is a legal requirement, not just good practice.

Know what is at stake

Under the EU AI Act, using a prohibited AI practice can lead to fines of up to €35 million or 7% of worldwide annual turnover, whichever is higher. Most other breaches can reach €15 million or 3%. For SMEs and start-ups, the lower of the two figures applies.

Fines are not the only exposure. Privacy laws such as the GDPR, the UK GDPR, California’s CCPA and India’s DPDP Act apply to the personal data your AI processes. In the US, the Federal Trade Commission has also acted against deceptive claims about AI products. Check current law and transition provisions before you commit to a launch date.

Checklist

List every AI feature in your product, including ones built on third-party APIs.
Write a one-page system map for each feature, with a named owner.
Flag any feature that influences hiring, credit, insurance, housing, education or essential services.
Record your role for each feature: provider, deployer or both.
Review vendor contracts for data use, model changes, incidents and documentation.
Add AI disclosures and content labels where users interact with or receive AI outputs.
Define when human review is required and how people can challenge an output.
Set logging, testing and change-management practices before launch.
Align your governance process with NIST AI RMF or ISO/IEC 42001.
Review each system map when the model, purpose or market changes.

FAQs

We only use a third-party model through an API. Are we covered by AI laws?

Often yes. Under the EU AI Act you are usually a deployer, with duties of your own, and you may become a provider if you rebrand, substantially modify or repurpose a high-risk system. Privacy and consumer laws also apply to how you use the outputs.

Does the EU AI Act apply if we are based outside the EU?

It can. It covers providers placing AI systems on the EU market and providers and deployers whose AI outputs are used in the EU, wherever they are based.

Is NIST AI RMF or ISO/IEC 42001 certification enough to comply?

No. NIST AI RMF is voluntary guidance with no certificate, and ISO/IEC 42001 certifies a management system, not legal compliance. Both help you organise the work and show buyers you take it seriously.

The EU high-risk deadlines moved. Can we pause?

The Digital Omnibus deferred stand-alone high-risk obligations to 2 December 2027, but prohibited practices, general-purpose AI duties and transparency duties already apply. High-risk compliance also takes quarters to build, so use the time rather than waiting.

Who should own the system map?

The product owner for each feature, with input from engineering and legal. Legal can review it, but the people who build and change the feature are the ones who can keep it accurate.

Primary sources

European Commission · EU AI Act NIST · AI Risk Management Framework

General information, not legal advice.