The Vendor’s AI Model Did Not Change. But it’s Risk Did.

On Sept. 22, Reuters reported that Meta had been testing a “human concierge” for its Muse AI agent. Contractors were handling some of the phone calls requested through the agent. Employees raised privacy concerns. A Meta vice president acknowledged internally that starting contractor-placed calls without proper disclosure had been “a miss” and said the feature had been rolled back for now. The feature was being tested internally with Meta employees, not enterprise customers. But it raises a question for companies buying AI-enabled services: What can change even when the vendor and model version do not?

For a chief compliance officer, audit executive or third-party risk lead, the practical question is whether today’s service still matches the facts that mattered when it was approved. Most staffing changes at an AI vendor will not change that answer.

For several years, I was responsible for the end-to-end experience of a global network of more than 10,000 external mathematics experts who formed the human layer of an AI-powered learning product. When that network moved to a new provider, data protection, access controls, payment security and operational continuity had to hold through the handoff. The questions concerned who could access which information, where responsibilities had moved and how work and payments would continue. An expert network is not the same as an enterprise AI vendor, but that experience taught me to track the role, not the roster.

A model-change notice does not catch every service change

A contractual right to be told when an AI vendor changes its model is worth having. In a recent CCI article on bank AI governance, Elaine F. Duffus and Aoife May listed it among the vendor terms to consider. A model release, however, is only one way an approved service can change.

Suppose that, when a service was approved, an external reviewer sampled redacted outputs. Six months later, people in that role are resolving customer cases using full records. The vendor and model version are unchanged, but access has expanded and authority may have changed. The organization may need different privacy, security or customer-protection controls.

This does not mean tracking every person who joins or leaves the vendor’s workforce. Staff turnover is normal. Initial vendor diligence establishes whether a service is acceptable to use. After approval, the task is to notice when the facts behind that decision stop being true.

A Gartner survey of third-party relationship owners found that when they observed a change in the scope of a relationship, only 52% reliably shared it with compliance. Relationship owners are often the first people inside an organization to see that something has changed. They may not know which changes matter to the control function.

“Tell us if anything changes” is therefore a weak monitoring instruction. Give the business owner a more concrete trigger.

Put four facts about the role in the approval record

NIST’s AI Risk Management Framework Playbook, under MANAGE 3.1, calls for regular monitoring of third-party AI risks. It also notes that documenting the technologies, personnel and other resources used can help manage those risks. It does not say which facts about personnel to keep.

For an external human role that materially supports an AI service, I would record four facts at approval.

•     Function and authority: Does the role sample outputs, resolve exceptions, moderate content, complete tasks the AI cannot or communicate with customers? Can the person advise only, or can they approve, send, pay or otherwise act? “Human oversight” is too broad a label to preserve that distinction.
•     Access: Record what the role can see. Redacted output and a full customer file are not the same risk simply because both sit behind the same model.
•     Delivery: Does the vendor provide the role directly, or does it use another provider? Record any part of that arrangement that matters to data flows, contractual protections or dependence on that provider. There is no need to assess every downstream worker.
•     Reliance: How much does delivery of the service depend on this role? Human involvement is not itself a weakness, and occasional help is different from relying on people for a significant share of the work. Frequency alone does not settle it: A role can be critical even if it handles only a few cases. Vendors also have reasons to lean on people. According to Reuters, a Meta executive wrote that some tests suggested having humans place the calls could raise their success rate to 95% to 98%, above AI-only calling.

Ask the vendor to confirm these facts in writing. For higher-risk services, agree what evidence will support later checks, such as updated role descriptions, access-control summaries or relevant assurance reports covering the service you use. If the vendor cannot confirm a material fact, document the gap and send it to the relevant risk owner. Do not treat a missing answer as confirmation that nothing has changed.

For any change, ask: If this had been true on Day One, could it reasonably have changed the approval decision or the controls attached to it?

A change that does not meet that test can remain an operational matter. Otherwise, send it to the team responsible for the affected risk. Broader access belongs with privacy or security. New authority to act for a customer calls for legal review and a look at customer impact. If human support has become essential or moved to another provider, check business continuity and exit plans.

Usually, the organization can revisit the affected part of the approval rather than restart the entire vendor assessment.

Legal and procurement teams should compare the vendor’s notice obligations with these facts. Depending on how they are written, clauses about incidents, model releases or named subprocessors may miss changes in human roles. Agree which material changes need notice, rather than relying only on the vendor’s definition of a model update.

At periodic reviews, the business owner can ask whether any external role has gained materially broader access or authority, moved to a different delivery arrangement in a way that affects risk, or become significantly more important to service delivery. Check the answer against the agreed evidence.

I would keep this in the third-party risk, privacy, procurement or operational-risk process that already owns the decision and would not build a separate AI-governance workflow for it.

Give internal audit a mismatch it can test

The Institute of Internal Auditors’ Third-Party Topical Requirement took effect Sept. 15, 2026. When an internal audit function provides assurance on third-party risk, the requirement establishes a baseline for assessing third-party governance, risk management and control processes.

For an AI service selected for review, I would give internal audit two questions: Does the service delivered today still match the relevant facts recorded at approval? Where it does not, did the change reach the right owner and result in a documented decision?

Return to the earlier example. The approval record says an external role samples redacted outputs; the current service uses people in that role to resolve customer cases from full records. Internal audit can ask when the change occurred, who reviewed the new access and what the organization decided. It does not need to reverse-engineer the model or obtain the vendor’s workforce roster.

Meta’s employees could see the test from inside the company. An enterprise customer may never have that view. The approval record gives the organization something concrete to test: whether the service it is using today still matches the facts on which it was approved. The model version does not.