Case: Scaling AI Without Losing Data Control

In this invented case, a mid-sized property and casualty insurer has put three AI features into production in eighteen months, each built by a different domain team. The claims team runs an assistant that summarizes claim files for adjusters. The policy-service team runs an assistant that answers agents’ questions about policy wording. The special investigations unit runs a model that scores new claims for referral. The quarterly review turns up three problems. An adjuster who had been removed from a litigation team could still retrieve summaries of that team’s files the next day. The policy assistant quoted an endorsement that had been replaced five days earlier. And the referral model’s referral rate had slowly dropped for six weeks before investigators noticed, because the claims-intake system had changed how it reports the loss amount.

Nobody in the room disputed that each problem was fixable. The argument was over whose problem it was. Claims said the index was the platform’s. The platform team said it had provided the storage, not the permissions or the documents. The investigations unit said its model had not changed. Meanwhile nine other domains have asked for AI features of their own, and the executive committee wants an answer at the next planning cycle. The VP of Data Platform has to say which decisions belong to the domains, which belong in shared capabilities, and how many of the nine requests to accept.

What stays in the domain and what becomes shared

The data mesh literature gives a vocabulary for this split. Zhamak Dehghani’s account on Martin Fowler’s site names four principles: domain ownership, data as a product, a self-serve platform, and federated computational governance. Domains answer for the data they serve. The platform gives them infrastructure they can use without specialist knowledge. Governance rules are agreed by the federation and implemented by the platform, so compliance is checked by software instead of by a review meeting. That description is about analytical data, and an AI feature adds new consumers of the same data, along with a retrieval index, a model, and an evaluation test. The same logic extends to them if each decision is placed where the knowledge and the leverage are.

Two questions place a decision. Who understands what a correct answer looks like? That party owns the decision, because a central team cannot judge whether a policy summary omitted an exclusion. And if each team handled the matter its own way, would the organization carry a risk that no single team bears, or would every team rebuild the same machinery? If so, the mechanism belongs in the platform, with the domain supplying the rules it enforces. Applied to the insurer, the split looks like this.

Decision	Domain team decides	Shared platform provides	Why it sits there
What data means and when it is wrong	The data product owner in the source domain	Catalog and lineage records that show who consumes each field	Only the source domain knows what a change to a field does to its meaning
Who may see which records	Classification of the data and the rule for who needs it	Enforcement on every retrieval path, with no opt-out	A missed check exposes the whole company, not one feature
How current data must be	The feature owner states the need; the source owner commits to it	Measurement of delay and alerts when the commitment is missed	The need comes from the decision, the commitment from the producer, the measurement from a neutral party
Whether a feature is good enough to release	The evaluation set and the acceptance criteria	A harness that runs versioned tests and stores results; a reviewer outside the feature team applies the gate	The builder knows the task; independence matters for the verdict
Whether a feature keeps running	The feature owner, who may stop it at any time	A stop switch, usage records, and a retirement process	Accountability follows the outcome; the means to stop must be common
Models, keys, quotas, versions	Which approved model fits the task	The gateway and catalog described in Every Team Had Its Own Key	Capacity and cost cross team boundaries

The split has costs, and the VP should name them to the committee. Moving enforcement into the platform makes the platform a dependency for every feature and turns it into a queue when it is slow. It also removes freedom from domains in exactly the places where they had no good reason to differ. Leaving enforcement in each domain keeps teams fast until the first incident, and then the company discovers that nine teams interpreted a rule nine ways. Operating models work when each class of decision has a named decider and a route for exceptions, and that is the test applied below to each failure. The ownership roles behind the left column are the ones described in Who Is This Table For?: a data product has a consumer, a contract, and someone who answers when it is wrong.

Access: the index remembered a permission that no longer existed

The claims assistant retrieves from an index of claim notes. When the notes were ingested, each carried a copy of the claim’s access list taken at ingestion, and ingestion ran nightly at 2:00 a.m. A claim moved into litigation was restricted in the claims system at once, but the index kept the old list until the next run. An index of this kind is a second system holding authorization state, and a second copy of state can disagree with the first. A revocation has to reach every path that authorizes a request, including this one.

How long the disagreement lasts depends on the design. Suppose, as a hypothetical, that thirty revocations happen in a week and they fall evenly across the day. With a nightly snapshot, each revoked person keeps access until the next run. The wait averages twelve hours and can reach twenty-four, so the week accumulates 30 × 12 = 360 person-hours of access that policy says should not exist. If the retrieval service instead asks the source system whether this user may read this document, and caches the answer for at most fifteen minutes, the wait averages 7.5 minutes and the week accumulates 30 × 7.5 ÷ 60 = 3.75 person-hours. A cache-free check would shrink that to nearly zero at the cost of an authorization call per candidate document. Neither number is right in general. The policy has to state the permitted delay for each class of data, and a litigation file may tolerate none.

The control belongs where every request passes, which is the idea behind a policy enforcement point: something that actually blocks the operation, as distinct from a rule that exists in a document. The OWASP guidance for large language model applications names this risk under vector and embedding weaknesses and recommends permission-aware vector stores with partitioning between user groups, along with logging of retrieval activity. A common design filters coarsely in the index by label and then checks the live permission before any passage reaches the prompt. A prompt that tells the model to withhold restricted material is not a substitute, as Last Year’s Policy, Cited Correctly explains. How roles and attributes are combined into the rule itself is covered under role-based and attribute-based access control.

The ownership follows from the placement. The claims domain classifies its data and states who needs it, because only claims knows which files are litigation-restricted and why. The platform builds the retrieval path that consults the live permission and does not let a feature skip it. The platform also runs a standing test: revoke a test account’s access, query within the permitted delay, and confirm that nothing comes back. The result is reported to whoever carries the control risk, so the claim “access is enforced” rests on a recurring measurement.

Freshness: a number the consumer sets and the producer reports

The policy assistant’s index was rebuilt every Sunday. Data freshness is a statement about how current data must be for its use, with a reference time, a point where it is measured, and an acceptable delay. The weekly rebuild implied a delay of up to seven days, but nobody had set a requirement, so nobody could call the seven days a breach. The first task is to derive the requirement from the decision. An agent who quotes coverage during a call is relying on the text to be current when the policyholder hangs up, so a change to wording has to reach the assistant within hours, not days.

The arithmetic shows what the choice buys. Suppose, hypothetically, that the assistant covers 600 policy documents, that 24 of them change in a month, and that 3,000 questions a day spread evenly across the documents, which is 5 per document per day. If changes land at random times, a weekly rebuild leaves a changed document stale for 3.5 days on average. That is 5 × 3.5 = 17.5 questions per changed document that touch text which has since changed, or 24 × 17.5 = 420 questions a month. Only the questions that depend on the changed passage are actually wrong, so 420 is an upper bound, not a count of errors. An update triggered by the change itself, with a one-hour target, leaves a changed document stale for 30 minutes on average. That is 5 × 0.5 ÷ 24, about 0.1 questions per document, or 2.5 a month. The gap between 420 and 2.5 is what the faster pipeline buys, and the committee can weigh it against the cost of building change notification and validated activation.

Who owns which part is easy to get wrong. The policy-service team, as consumer, sets the requirement. The team that owns the policy documents commits to it in the data contract for that product, which states what consumers may rely on. The platform measures the delay from source change to availability in the index, document by document, and alerts when the commitment is missed. A breach is then an event with an owner instead of an observation in a retrospective. Freshness addresses delay only. Whether the old version is still eligible to be retrieved after the new one arrives is a version-selection problem, covered in the retrieval article above.

Evaluation: who writes the test, who runs it, who can say no

The referral model passed its weekly evaluation every week while its behavior drifted. The test used a frozen validation set whose loss amounts were recorded under the old definition. Meanwhile the claims-intake team had changed the field from gross loss to loss net of the deductible, as part of its own system update, with no one asking who consumed the field. A frozen test detects regressions in the model. It cannot detect a change in the meaning of live inputs, which is why this failure needed two different controls. The first is a contract on field meaning, with change notice to consumers registered in the catalog and lineage records. The second is monitoring of the live input distribution and the referral rate, owned by the unit that owns the model. This is the loop described in The Model Nobody Owned, applied to a model whose inputs belong to another domain.

The same review looks at how features are released. For the policy assistant, the domain builds an evaluation set of 200 questions with approved answers and a release gate that requires at least 90% of them to pass. A candidate passes 184, or 92%. That sounds like a clear pass, but 200 questions are a sample, and the Wilson score interval, which behaves well for proportions near 1, puts the 95% interval for the true pass rate between 87.4% and 95.0%. The data cannot rule out a true rate below 90%. A candidate that passes 190 (95%) has an interval of 91.0% to 97.3% and clears the threshold. Showing that an observed 92% exceeds 90% with this confidence takes about 900 questions, since 828 of 900 gives a lower bound of 90.04%.

So a threshold and a sample size are one decision. Building and labeling questions costs domain experts’ time, and the choice is between a larger set, a lower-risk definition of the threshold, and a design where the cases that matter most are checked separately. The insurer takes the third path: a short list of critical cases, such as coverage exclusions, must all pass regardless of the total, and the remaining questions are judged on the lower bound of the interval. The details of building sets and judging answers are in The Judge Preferred Longer Answers. What matters here is who does what. The domain writes the set, since it knows what a correct answer is. The platform keeps the set and every result versioned and runs the same harness for every feature, so scores stay comparable. The gate is applied by a reviewer outside the team that built the feature. The NIST AI Risk Management Framework playbook, in its Govern function, calls for roles and lines of communication across product, development, testing, and compliance, and for keeping development separate from testing so the verdict is independent.

Operating accountability: who is paged, and who can stop it

In the review, nobody was ignoring an alert. There was no alert and no one to receive it. A production AI feature needs a short list of named roles, defined in terms of what each can decide. Responsibility and accountability are different. Many people may do the work, but one party must answer for the outcome and must have the authority and the means to impose conditions or stop the feature. At the insurer the roles are as follows.

• The feature owner, in the domain, is accountable for the feature’s outcomes and receives the first page when an answer is wrong. The owner can stop the feature without asking anyone.
• Each data product owner is responsible for the data the feature consumes. A freshness breach or a field change goes to that owner, who also receives the notice when a consumer reports a problem.
• The platform’s on-call role covers the shared components: the retrieval service, the permission checks, the gateway, and the evaluation harness. It also owns the health of the monitors themselves.
• A risk or control function outside the feature teams receives the access-test and gate results and can order a feature stopped. It restarts only on evidence that the condition is cleared.

An incident then follows a path instead of a debate. The feature owner starts from the traces of the failing answer and places the fault: retrieval returned the wrong passage, the passage was right and the model misused it, or the data underneath had changed. Each finding routes the work to the owner of that layer. The first page goes to a role with an acknowledgment time, not to a shared channel. Two cases need an agreement made in advance. When the cause is unclear, the feature owner keeps the incident until another owner accepts it. And when the data is at fault, the feature owner decides whether to continue with a manual fallback or to stop.

Ownership also needs an end. Features outlive their builders, and a model with no named owner is a risk nobody is watching. The insurer adopts a rule: a feature whose owner leaves is suspended from taking new users until a successor is named, and one that stays unowned goes on a retirement list. The NIST playbook’s Govern function treats this as part of the lifecycle. Its decommissioning guidance asks organizations to consider dependencies upstream and downstream, business continuity, legal requirements, and where retired artifacts and records will be kept. A switch that stops a feature is useful only if the plan for what the business does afterward exists before it is pressed.

Expansion: which of the nine, and in what order

Every decision above reappears as a condition for admission. A request for a new AI feature arrives with the following, or it is not ready for the shared path.

• A named feature owner and an owner for each data product the feature consumes, with the decisions each can make.
• The data classified, and the retrieval path routed through the platform’s permission check, with the permitted revocation delay stated for each class.
• A freshness requirement derived from the decision the feature supports, accepted by the source owner in a contract.
• An evaluation set and a gate whose threshold and sample size were chosen together, with the critical cases listed.
• An on-call arrangement, a stop path, and a retirement plan.

The reason for insisting on readiness is capacity. Suppose, hypothetically, that the platform team has four engineers with twelve productive weeks each in the quarter, which is 48 person-weeks. It reserves 40% for run work: on-call, upgrades, and moving the three existing features onto the shared permission path, which are not exempt. That leaves 19.2 reserved and 28.8 available. A request that arrives ready costs 7 person-weeks to onboard. A request that does not costs 14, because platform engineers end up doing the domain’s work, such as mapping permissions, setting up freshness measurement, and drafting the evaluation set with it. Three of the nine arrive ready. The nine together would need 3 × 7 + 6 × 14 = 105 person-weeks, about 3.6 times the 28.8 available.

Admitting the three ready requests uses 21 person-weeks and leaves 7.8. A fourth that still needs readiness work would cost 14 and does not fit. But if its domain finishes the readiness work first, at the domain’s own expense, it costs 7, and four features total 28 person-weeks, within the 28.8 available. The offer to the other domains is therefore concrete: the platform admits features in the order they become ready, and readiness is paid for by the party that benefits from the feature. The order of the later five follows the comparison of use-case value against data readiness developed in Fourteen Pilots and Nothing in Production. The platform publishes the admission conditions and templates so that meeting them is easier than working around them. As the earlier discussion of shared platforms notes, a platform that is slower than calling the provider directly gets routed around.

Expansion applies to features already running as well. A feature admitted for 40 agents does not move to 400 on enthusiasm. The next step needs production evidence: freshness commitments held through a full cycle of document changes, access tests passed on schedule, and gate results on production samples above the threshold, with the weakest segment reported. If a domain has a real reason to differ, such as a different retrieval technology, the exception is granted to a named owner for a defined time, and the substitute must meet the same permission, freshness, and evaluation conditions. An exception without those conditions only recreates the three failures from the review.

The VP takes the committee a decision, not a program description: four features this quarter, three ready now and one when its domain completes readiness; the remaining five queued in order of readiness and value; readiness funded in the domains’ budgets; and a quarterly report built from the freshness delay, the revocation test results, and the gate and stop events. The plan changes if the report does. An access test that fails would pause admissions until the path is repaired. A quarter in which several domains arrive ready would justify more platform capacity.

References

• Zhamak Dehghani, Data Mesh Principles and Logical Architecture, martinfowler.com.
• OWASP GenAI Security Project, LLM08:2025 Vector and Embedding Weaknesses.
• NIST AI Resource Center, AI RMF Playbook: Govern.
• Wikipedia, Binomial proportion confidence interval (Wilson score interval).