You Deploy AI. You Do Not Build It. The Obligations Still Reach You.

An estate where everything was bought

The question arrives from one of a few directions. A customer's procurement questionnaire has a line about the EU AI Act on page four. Counsel forwards something and asks whether it concerns the business.

The answer is honest as far as it goes, and what it describes is engineering. Obligations under the Act are tiered according to the risk a system presents, and they attach according to the role an organization occupies in relation to that system. Building is one way to occupy a role. Using a system somebody else built is another. Application is phased. Everything past that shape belongs to your counsel, and this article gives you none of it on purpose.

So the question is about systems, and it gets answered one system at a time. In an estate assembled entirely from purchases, the count runs higher than the procurement record shows.

• A hosted assistant licensed across the company, reaching whatever each person can already open
• A model feature enabled in a release of an application you have run for years, scoped to the data it already held
• A supplier who has placed a model inside a process your business depends on
• A product you bought that calls somebody else's model underneath, stated somewhere in the documentation
• An internal workflow a team wired to a hosted model API, which a weekly process now depends on

One estate, more than one role

Role attaches per system. The same company can occupy one role in relation to the assistant its staff use and a different one in relation to the thing its engineering team built on a hosted model. Provider and deployer are both defined inside the Act, and those definitions are what count. Your counsel applies them, and how quickly they can do it depends on whether somebody wrote down what your organization does with each system.

The determination leads somewhere, and it is worth knowing where. Where counsel places your organization as the deployer of a system in the Act's high risk tier, the obligations that follow include headings a security team will recognize: use in accordance with the provider's instructions, human oversight, the relevance of input data, monitoring the system in operation, and the retention of logs. Article 26 carries more than those five, among them duties to inform affected workers, to inform the individuals subject to the system, and to cooperate with the competent authorities, and Article 27 requires a fundamental rights impact assessment from a defined set of deployers. Each of those headings has a text, with conditions and exceptions, and reading them onto your systems is counsel's work. They are named here so you can see what the determination opens onto and what evidence your estate will be asked for.

Rows that were switched on and left as delivered look alike and settle fast. The ones that take a real conversation are where the organization did something beyond switching a system on: gave it a purpose beyond the one the supplier documented, put its own name in front of it, wired it into a workflow that produces something a customer reads. Whether any of that bears on the role is a legal question, and counsel answers it from facts about what your organization did.

Whether the Act reaches your organization at all turns on more than where the company is incorporated, which is a further reason the determination belongs to counsel. The security team's contribution is the evidence underneath it, and the determination waits on that evidence arriving.

A company has one registered address and as many roles as it has systems.

What counsel needs before they can answer

Counsel reads the law. What they cannot do is read your estate, and the question that reaches them is the wrong size. Are we in scope resolves one system at a time, and each of those answers is built from facts living in identity logs, SaaS admin consoles, contracts, source repositories and the heads of the people running the work.

Arrive with a list of tool names and expect to be sent back, politely, for the same list carrying everything that makes it usable. That second list is short, and the security function can fill every field on it.

A lifecycle assessment run against SAIL 2.0, the Secure AI Lifecycle Framework CWS contributed to, already produces most of these fields, because the rest of an AI program needs them anyway.

• The system, named, with an owner who has a job title and a manager
• What it is used to decide or produce, and who is affected when it gets that wrong
• Whose model it is, which company hosts it, and which contract governs it
• Whether your organization built it, configured it, licensed it, or inherited it inside a product it already ran
• The data classes that reach it, and whether any of them leave the organization
• Whether the output reaches anybody outside, and whether that person is told a model produced it
• Where the system runs, and where the people affected by it are
• What has changed about how it is used since the day it was bought

The rows worth putting at the front

Counsel's attention is the scarce thing. A register of a hundred rows landing at once produces a slow reading and one general answer covering everything, so sort it first. Most of a bought estate is repetitive and travels well in a single block with one description over the top.

What goes at the front is the small number of rows where a careful person could argue the answer either way, or where being wrong reaches somebody outside the company.

Every item below is a fact about your organization's own conduct, which is why the security function can gather all of it. What those facts mean is the part counsel is there for.

• Anything whose output reaches a customer, an applicant or a member of the public
• Anything informing a decision about a person, including hiring, access, credit, eligibility or performance
• Anything a team here built on a hosted model and then put in front of somebody outside
• Anything running under your organization's name where the model came from elsewhere
• Anything used for a purpose beyond what the supplier documented
• Anything reached by data classes your own policy says must stay inside

Counsel reading a hundred undifferentiated rows produces one general answer, and a general answer is what gets quoted back at you a year later.

Where security teams create their own exposure

Two failures show up here, and they run in opposite directions.

The first is settling the question quietly. Somebody types a role into a spreadsheet column because the column needed filling, the file gets attached to a board paper, and nine months later it reads as a determination. The only person who ever touched that cell worked in security, and has since changed jobs.

The second is waiting. The register stalls pending legal clarity while counsel waits for a list of systems, and both sides believe the other one is blocking. Every field described above can be collected before anybody determines anything. Start collecting.

Both failures leave marks on the register, and these are what they look like.

• A role written into a register by somebody in security and carried forward as settled
• A determination made once and left alone after the system's use moved on
• A register assembled from procurement records, which covers only what came through a purchase order
• An answer given to a customer's questionnaire, with the evidence for it still to be assembled
• The whole question parked until counsel says something, while counsel waits for the list

A guess typed into a spreadsheet column carries the authority of whatever document that spreadsheet ends up inside.

What to hand over, and who keeps it current

The meeting is short when the pack is right. It is the register, sorted, with the arguable rows at the front and a written statement of what was left unexamined. A register claiming completeness fails on the first question, so give it a stated confidence position and name the sources you were refused.

Where the line falls between what a security function produces and the legal determination it does not make is a CWS position on division of labor, and the cover page is where it gets stated. Say plainly what the pack is. The security function produced facts about systems, using access that sits with the security function, and every role marked anywhere in it is a proposal awaiting counsel's confirmation. Counsel makes the determination. That sentence on the cover keeps the document honest when somebody finds it next year and reads it as a conclusion.

Then the maintenance, because a determination holds only while the description it was made against is still accurate, and descriptions move. A feature appears in an installed product. A team extends an internal build. The intake path and the recertification cycle the rest of the AI program already runs are what keep the register current, and the determinations with it.

Settle the list below before anybody starts pulling data.

• The register, a row per system, with the fields filled and the gaps marked as gaps
• The arguable rows at the front, each carrying a line on why it is arguable
• Every proposed role marked as a proposal for counsel to confirm
• A named person who maintains the register, and a route by which a new system reaches them
• A date the pack gets read again, set before the first change lands