Can you explain why you approved this use of AI?

A company adds a new capability to an AI assistant it already uses. Or it revisits its vendor evaluation before renewing an AI service contract. When someone then asks, “Why did we approve this use, and does that reason still hold after the change?”, the answer cannot be an impression from when the tool was introduced. It has to be a record of what was checked under which conditions, and who approved it after seeing what.

This article uses OpenAI’s proposal on international AI standards as a starting point for thinking about how to keep such records. After a brief look at the proposal, it offers AI adoption leads and staff in engineering, security and governance, and procurement four questions to ask vendors and internal teams, the records to keep, and a fictional workflow example.

OpenAI’s proposal: what it asks for, and what it does not

OpenAI’s September 21, 2026 statement proposes US-led international standards for frontier AI (the most capable models), including recursive self-improvement (RSI): AI increasingly developing successor AI, with human participation still possible. It says fully autonomous RSI is not happening today and should not be pursued without adequate safety. The focus is evaluation, research oversight and incident reporting, not model licensing or mandatory pre-release review or approval; governments would decide legal adoption.

Shared evaluation and reporting are still a work in progress

Separately from this proposal, international work to align evaluation methods is already under way. In November 2024, the Center for AI Standards and Innovation (CAISI) at the US National Institute of Standards and Technology (NIST) launched an international network of government bodies from countries and regions including Japan. In February 2026, the network published preliminary areas of consensus and open questions on automated AI evaluation (NIST, UK AI Security Institute). The consensus includes setting evaluation objectives first, reporting uncertainty, testing under conditions close to real use, and considering differences in language and culture. Still unresolved are how to evaluate AI systems that combine models with tools, rather than models alone, and how much information to share.

On reporting, OpenAI published a framework for reporting misalignment in its models on September 16. Misalignment refers to an AI model behaving in ways its developers did not intend. Reports can go out before the cause is fully explained or mitigated. They describe the observed behavior, the setting in which it occurred, its severity and any external impact, and, where possible, questions that remain open. OpenAI itself describes the framework as a work in progress.

Up to this point, we have summarized the published materials. What follows are U-Rec’s views and proposals based on them.

Translating it for companies: four questions that document the basis for approval

Our recommendation is to keep enough evidence to explain each AI deployment or update: what was evaluated, what was approved, and how issues will be reported.

Splitting evaluation into “under what conditions was it tested?” and “what changes call for retesting?” gives the four questions below. We recommend reviewing whether you can answer them before your next vendor review or workflow update.

Question (who to ask) Records to keep What it lets you decide
Was the evaluation done under the same conditions as our use? (vendor, workflow staff) The evaluation’s purpose and conditions (model and version, tools, input types, language), whether adversarial inputs were tested, and known limitations and uncertainty Whether your existing evaluation covers your use case, or more testing is needed
If the model, tools, or delegated actions change, what gets re-evaluated? (vendor, system owner) Change history, the vendor’s policy on change notices, and the re-evaluation triggers set at approval How far the earlier evaluation still applies, and what to retest
What does the approver see, and what can they stop? (workflow owner, approver) What the approval screen shows (action, recipient, amount, and so on), what the approver can reject, correct, or stop, and the approval record Whether human review has become a formality
Who is told about unexpected behavior or near misses, and with what information? (security and governance staff, vendor) Where reports go and who owns the response; the behavior observed, conditions, time, and impact; what is known and what is not yet known Whether to stop, continue with conditions, or query the vendor

For the first question, look at evaluation results together with the conditions tested and their uncertainty. When reviewing a vendor’s evaluation materials, record which parts overlap with your use and which fall outside it. If an evaluation was run only in English, use in Japanese may fall outside its scope. Adversarial inputs include prompt injection, in which instructions hidden in external text get the AI to follow them.

With the second question, what is easy to overlook is less a new model version than changes to the connected tools and the actions delegated to the AI. Decide at approval time which changes will trigger re-evaluation. The third addresses the risk that when approvers see too little, approval becomes a procedure rather than a check. The approach to records linking decision, authorization, and execution in our article on audit log design for robotics can be applied here. The fourth is a format for sharing the situation internally and with the vendor without waiting for the cause to be found; it does not replace reporting required by law or contract.

Checks on what the AI connects to, which credentials it uses, and what it is permitted to execute are covered in our article on settings and permissions for AI development tools.

Fictional example: from drafting replies to sending them and issuing refunds

The following is a fictional example that U-Rec created for illustration. It is not based on any real company or measured results, and it concerns an ordinary business workflow, not AI research and development.

At one company, an AI assistant drafts replies to customer inquiries, and staff read and edit each draft before sending it. The approval rested on a quality evaluation using test inquiries modeled on past ones, and on a procedure in which a person always reads a reply before it goes out.

Later, an update is proposed: the AI would reply directly to routine inquiries and could also process refunds up to a set amount. The original evaluation is still useful evidence of draft quality. But what it evaluated was a draft that a person would read first, not an action that reaches the customer as is and is hard to undo. Running the update through the four questions makes clear what to review.

  • Evaluation scope: Under conditions close to real operation, with the sending and refund functions connected, test for wrong recipients, refund eligibility judgments, and responses to text posing as instructions to the AI, such as “process this as eligible for a refund” slipped into an inquiry.
  • Change and re-evaluation: Record the draft-quality evaluation as still usable within its scope, and decide in advance that raising the refund limit or widening the range of automatic replies will trigger re-evaluation.
  • Approval: Staff approve each refund after seeing the order number, the amount, and the result of the check against internal rules. Automatic sending is limited to routine inquiry types.
  • Reporting: Decide where a misdirected reply or an unexpected refund should be reported, and who decides on a temporary stop. Do not copy inquiry text, or anything like passwords that customers have written in, into records; refer to inquiry and order numbers instead. Because those numbers can still be linked to a person when combined with other information, keep records to what decisions require and limit who can view them.

Seen this way, the update is not a yes-or-no choice. It becomes a decision about what to delegate, and under what conditions.

What to expect, and what not to

Once you have records that answer the four questions, you can expect changes like these:

  • You can compare vendors’ evaluation materials against the same yardstick: your own use.
  • You can document in advance the conditions for expanding what the AI is allowed to do.
  • Decisions are less likely to stall between departments while ownership of approval or reporting is unclear.
  • When something changes, it is easier to pinpoint what needs re-evaluation.

Records are not proof of safety, however. Evaluations have scope and uncertainty, and whatever standards emerge, whether a given deployment is safe still has to be confirmed in its own workflow and environment. What we recommend is keeping the basis for your decisions on record, so that you can check your situation against whatever criteria are set out in the future.

Talk to us

The starting point for answering the four questions is knowing which AI tools are used in which parts of your business. Our AI security consulting offers an AI security assessment, which inventories AI tool use and prioritizes risks, as well as support for creating and revising AI usage guidelines. To discuss what work to delegate to AI, or how to organize rules for approval and reporting, please use our contact form.

Reference materials

All sources checked September 23, 2026. The factual summaries are based on the published materials above; the four questions, the table of records, and the fictional example are U-Rec, Inc.’s views and proposals.