Responsible AI Has an Interoperability Problem

Vendor A gives you a model card.

Vendor B gives you a safety report.

Vendor C sends benchmark scores and a 72-page PDF that turns out to be a security whitepaper.

Vendor D says its system is “enterprise-grade responsible AI.”

Procurement asks the obvious question: can we compare any of this?

Usually, not cleanly.

Enterprise AI has quietly become a supply chain: a model from one provider, fine-tuned by an integrator, retrieving from a vector store bought on a separate contract. Governance information about that chain arrives in incompatible dialects. One talks about safety, another about trust, a third about its own five-tier risk taxonomy. One sends an ISO 27001 certificate and a SOC 2 Type II report, which say a great deal about its security and control environment, and say nothing directly about how the model behaves when a customer writes to it in Portuguese.

All perfectly serious. Still messy.

Model Cards¹ and Datasheets for Datasets² mattered because they formalised communication between those who create AI artefacts and those who use them downstream. Enterprise AI now stretches that relationship across a much longer supply chain.

The harder problem is translation. There is plenty of information. What is missing is enough shared structure to make sense of it across organisations. Here, governance evidence means the material behind a supplier’s claims about how a system was designed, tested, controlled and monitored.

Governance Has a Hidden Translation Cost

Picture a mid-size insurer evaluating three vendors for a claims triage assistant. The example is illustrative, but the coordination problem is not.

Security maps each supplier into a control framework written for SaaS applications, with no concept of a model version. Privacy stalls on whether prompt logs are personal data when the prompts contain claim narratives. Legal drafts indemnity clauses, then finds the vendor’s training-data disclosure runs to a single sentence. The responsible AI team, both of them, translate three evaluation vocabularies into something the risk committee will recognise. Procurement chases evidence. Everyone waits.

Eventually, the committee approves the vendor that answered fastest. That may have very little to do with which vendor answered best.

The problem wasn’t only missing information. It was the absence of a common structure for interpreting what had been provided.

There are really four different problems hiding inside this.

Semantic interoperability is the most obvious. Two teams can both use words such as “high risk,” “evaluated” or “human oversight” and still mean different things.

Evidence creates another problem. An evaluation is only useful downstream if you can tell what was tested, under which conditions, where the evidence came from and whether somebody else can reproduce or rely on it. A polished report is not automatically portable evidence.

Then there is what happens after deployment. If the provider changes the underlying model tomorrow, does anybody on the customer side know? More importantly, does anything happen because of it? A model change hidden behind an unchanged API version is still a model change.

And organisations create their own interoperability problem. The same AI system can appear in a cyber register, a privacy assessment, a model-risk inventory and a legal review under four different classifications. At some point, somebody has to be able to tell that they are all talking about the same thing.

The OECD has treated interoperability among AI risk-management frameworks as a policy problem, and found real commonality across major approaches even where vocabulary differs.³ Encouraging, because the alternative is that every supplier relationship becomes a bespoke governance integration.

AI Needs a Minimum Governance Interface

What I have in mind is much smaller than a global governance regime: a common baseline for the components that can materially affect an outcome, a control or a compliance obligation.

At minimum, that record should tell a buyer what the component is, which version is running, who supplies it and what sits underneath it. It should say what the system is meant to do, where it should not be used, what is known about its training and evaluation data, and where performance starts to weaken. It should also cover retained customer data, expected human review, model-change notifications, incident reporting and, critically, which claims are backed by evidence the buyer can actually inspect.

Nothing on that list is unusual. That is precisely the point. Governance interoperability should make basic comparison boring.

There are limits, obviously. Vendors will not disclose everything, nor should they. Some evidence can be independently attested rather than handed over, and commercially sensitive information may have legitimate reasons for staying confidential. What matters is that “we cannot disclose this” also has a recognised place in the structure instead of simply leaving a blank.

Someone would eventually have to maintain that baseline too. A standards body? An industry consortium? Something else entirely? I do not think that question is settled yet.

Europe is already moving in this direction in pieces. The EU AI Act requires technical documentation for high-risk systems to be drawn up and kept up to date, and Annex IV asks for information including intended purpose, provider, system version and relevant interactions with other systems.⁵ ISO/IEC 42001 approaches the problem from the organisational side through an AI management system standard.⁶ Neither gives buyers the cross-vendor interface described here, but the underlying idea of maintaining structured governance information is hardly radical.

Operational interoperability is where this fails most quietly. A provider ships a point release. The base model underneath changes. Nothing in the API contract moves, so nothing triggers a review. Some time later, an operations lead notices extraction accuracy has slipped on scanned documents, and the ticket is logged as a data quality issue. Nothing about that chain of events is exotic. It’s the ordinary consequence of buying a system whose behaviour is versioned and whose governance isn’t.

A contract does not need a grand theory of interoperability to catch this. “Tell us when the underlying model changes, even if the API does not” would already close part of the gap.

This Is Also a Competition Problem

Buyers who struggle to compare suppliers also struggle to put pressure on them. Fragmentation therefore creates a switching cost that has little to do with the actual code.

Moving from Provider A to Provider B might be technically straightforward: some API changes, some prompt tuning, a fortnight of integration work. Then governance arrives. A risk taxonomy that doesn’t map onto the one your committee approved last year. Evaluation evidence in a different format. A fresh approval cycle, a new legal mapping, new monitoring thresholds.

Of course, changing models can require genuine re-validation. That work does not disappear with better standards. What should disappear is the need to translate essentially equivalent evidence from scratch simply because two suppliers package it differently. That is the interoperability tax.

For a regulated buyer with formal approval cycles, that extra work can easily become larger than the technical migration itself. The paperwork may turn out to be stickier than the technology.

Vendor lock-in is not only technical. It can be regulatory, evidentiary and organisational. Which makes interoperability a question of market portability, not just compliance efficiency. Buyers who can’t compare suppliers have a harder time disciplining them.

The Same Mess Exists Internally

Large organisations reproduce the problem inside their own walls. Cyber has one classification scale, privacy another. Model risk, in a regulated firm, has a third with a decade of methodology behind it and no obvious slot for a language model. Legal has a fourth. The executive committee receives four risk colours for the same system and, reasonably enough, stops reading.

Cyber should keep assessing cyber risk. Privacy should keep privacy. Model risk has its own job too. The point is not to flatten those disciplines into one methodology. They just need somewhere to meet.

What’s missing is a shared spine: one identity for the system, one accountable owner, one intended-use statement, one lifecycle stage, visible model, data and vendor dependencies, with specialist assessments attached to that record rather than scattered across four registers.

Ideally, the record works in both directions. The supplier answers the external version of it. Inside the company, the same basic identity follows the system across cyber, privacy, legal, procurement and model-risk assessments. One system, several specialist views.

Portfolio questions then become answerable. How many of our systems depend on a single provider is a question increasingly reaching boards and executive committees, yet one many organisations struggle to answer quickly. NIST’s Generative AI Profile notes that generative value chains may draw on third-party datasets, pretrained models and software libraries, raising the need to understand component dependencies and downstream accountability.⁴ Dependencies you can’t name are dependencies you can’t govern.

Please Don’t Build a 200-Question Form

Standardisation has a dark side, and governance teams walk into it. We love forms. Long ones. Every incident adds a question, few get removed, and within three cycles the questionnaire is a ritual that vendors answer with boilerplate and buyers skim.

What matters is not collecting the maximum possible amount of information. It is collecting enough of the right information to make a decision: what am I buying, where is it weak, what can change without me, and what happens when something fails?

That’s a first layer. Deeper due diligence should follow risk, not uniform curiosity. A model drafting meeting summaries doesn’t warrant the scrutiny of a model screening credit applications, and treating them alike is how governance teams lose the room.

Keep the baseline stable. Let the scrutiny deepen with the risk.

Proportion matters. Always.

Trust Needs a Protocol

Software scaled because systems stopped inventing a new language every time they connected. The protocols underneath the internet aren’t dull. They work so well that almost nobody has to think about them.

AI governance will get there, probably the slow way. One organisation creates a model, another integrates it, a third deploys it into a regulated process, a fourth audits it two years later. Trust information has to survive that chain, and too much is lost between the first step and the second.

The next useful advance in responsible AI may therefore be considerably less glamorous than another principles document. It may simply be a shared way of saying: this is the system, this is what we know about it, and this is what you should keep watching.

A company does not need to wait for an international standard to start. It could begin with the next procurement and ask every supplier to answer the same small set of questions.

Boring? Good. That is what infrastructure looks like once it grows up.

References

¹ Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D. and Gebru, T. (2019), ‘Model Cards for Model Reporting’, Proceedings of the Conference on Fairness, Accountability, and Transparency (FAT ’19)*, pp. 220–229. Association for Computing Machinery. DOI: 10.1145/3287560.3287596. Available at: https://dl.acm.org/doi/10.1145/3287560.3287596

² Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daumé III, H. and Crawford, K. (2021), ‘Datasheets for Datasets’, Communications of the ACM, 64(12), pp. 86–92. DOI: 10.1145/3458723. Available at: https://dl.acm.org/doi/10.1145/3458723

³ OECD (2023), Common Guideposts to Promote Interoperability in AI Risk Management, OECD Artificial Intelligence Papers, 7 November. DOI: 10.1787/ba602d18-en. Available at: https://www.oecd.org/en/publications/common-guideposts-to-promote-interoperability-in-ai-risk-management_ba602d18-en.html

⁴ National Institute of Standards and Technology (NIST) (2024), Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. Available at: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

⁵ European Union (2024), Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), Article 11 and Annex IV. Available at: https://eur-lex.europa.eu/eli/reg/2024/1689/oj

⁶ ISO/IEC (2023), ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. International Organization for Standardization. Available at: https://www.iso.org/standard/42001