AI Features Need an Owner for the Record

A support assistant tells a customer last year’s return window. The policy file was never retired. The model did not invent the window. It repeated a record nobody was responsible for correcting, in a voice that sounded current.

An AI feature is a new reader. It will treat what it can read as something it may say, unless the system around it is allowed to refuse. The missing piece is usually a named owner for the specific record the feature depends on. NIST’s AI Risk Management Framework treats trustworthiness as something designed into the system, not a property that arrives with the model. Record ownership is the practical form of that idea for a single feature.

The feature reads a record, not a program

“Data quality” is a program. A feature does not read a program. It reads this customer’s address, this policy clause, this price. For that read, five checks matter.

• System of record. One store is allowed to be right for this field.
• Writer. A role, not a department slogan, is allowed to change it.
• Correction path. A wrong value has a place to be fixed that the feature will see on the next read.
• Freshness. The feature knows how old the value is, or it does not use the value.
• Permission. The caller is allowed to see this record. Fluency does not expand access.

If any of those is undefined, the feature can still draft. It should not answer as if the draft were the record.

How an unowned record reaches a user

The same customer exists in the CRM and in billing, and the feature searches both. A wiki page and a PDF disagree, and retrieval returns the chunk that is closer in the index. A field is optional in the source system, so it is often blank, and the model fills the blank with a plausible value. That last case is a guess. The feature should abstain, which is the behavior described in When AI Should Refuse.

Retrieval can be current and still repeat a page nobody maintains. Keeping the index aligned with the source is covered in Production RAG: Data Freshness, Staleness, and Re-Indexing Strategies. Ownership is the part an index cannot invent: someone has to retire the old page, in the system the index copies from.

Permission fails in a related way. The application checks access, then a retrieval index serves text that was copied without the check. The caller’s permission has to travel with the record. Permission Boundaries for Enterprise AI is the longer treatment of that boundary.

Write the contract for the fields the feature may say

The ages in this table are examples of the kind of limit a team writes down. They are not recommended defaults. A price that can change within an hour needs a tighter rule than a policy that changes by version.

Illustrative scenario: quoting a discount

This scenario is illustrative. It is not a claim about a Vasiva deployment.

A sales assistant is asked to quote a discount. The number lives in a spreadsheet a manager edits, and later in the billing system. In a trial, the assistant quotes the spreadsheet. Deals close at a figure billing will not honor.

The repair is a rule about the record. Billing is the system of record for a discount that has been approved. The spreadsheet may remain a draft. The assistant may show the draft if it labels the number as unapproved. It may state a discount only when billing returns one, and the reply should carry the version or timestamp it read. If billing has no row, the assistant says it cannot quote. A prompt that says “prefer billing” does not implement that rule. The application does, by refusing to render a number the contract does not allow.

Checklist for the next feature that will answer from your data

1. List the fields the feature is allowed to state. Leave everything else out of the answer.
2. For each field, name the system of record and the role that may change it.
3. Define the correction path and prove that the next read sees the correction.
4. Set the maximum age, or the version rule, and refuse when the read is older.
5. Apply the caller’s permission before retrieval, and do not retrieve a copy that skipped the check.
6. Decide the sentence the feature uses when the field is missing. Write that sentence. Do not let the model complete the blank.
7. Review the contract when the feature’s job changes. A new question is often a new record, with a different owner.

Readiness belongs to the feature

A warehouse, a lake, or a search index can be useful and still leave a feature unready. A demand forecast and a policy assistant do not share an owner, a freshness rule, or a failure mode. Say which feature is ready, and which record it is allowed to speak for. A company-wide claim that “the data is ready for AI” hides the field that is not.

Questions that usually come next

Is the data lake the owner?

A lake is a copy. The owner is the role that can change the system of record and is accountable when the feature repeats a wrong value. If the only people who can “fix” the data are analysts editing the lake, the source will keep producing the same error.

How is ownership different from keeping a retrieval index fresh?

Freshness asks whether the index matches the source. Ownership asks whether anyone is expected to change the source, and whether that change is the one the feature will read next. A perfectly current index can still repeat a policy nobody maintains.