Admit a third-party model or AI API into the estate
Draft
Admit a third-party model or AI API into the estate
Allocation
| L2-02 | |
|---|---|
| Decides | Architecture Review Board |
| Consulted | Vendor Lead, CISO, DPO and Model Owner |
| Executes | Engineering |
| Evidence | Technical admission record referencing the vendor assessment |
In plain terms
Decide that an external model may be used at all, on technical grounds. Admission is not procurement and not authorization to deploy; both of those happen at Layer 4.
What is being judged
Whether this model can live inside the estate under the standards the estate runs on.
Four questions. Can it be reached under an approved integration pattern, or does it require an exception before it has done anything. Can it be evaluated, meaning does the provider expose enough about version, behavior and change for a Model Owner to validate against thresholds and detect drift. What happens when it changes, since a provider can deprecate, retrain or alter behavior on a schedule the organization does not control. What does exit cost, counted in prompt and evaluation rework rather than in contract terms.
The third question is the one most often skipped, and it is where third-party models differ most from other technology. An admitted model whose behavior can change under you without notice is a different governance object than a library version you pin.
What this decision does not cover
It does not contract, which is L4-VEN-01 and carries provenance and audit terms. It does not authorize production use, which is L4-AUT-01. It does not determine value-chain status, which is L4-REG-02 and fires later if the model is modified.
When it fires
On event. Before first use of a model from a provider or a specific model not previously admitted. On a provider’s material change to a model already admitted. When a model enters through a product feature rather than through engineering, which is the case the trigger is most likely to miss.
On cycle. Admitted models reviewed with the standards register.
What you need before deciding
The vendor assessment covering security and data handling. What the provider publishes about versioning, deprecation and change notice. Which data the model would see. The integration pattern proposed. Current provider concentration, from the Layer 4 aggregate exposure assessment.
How this goes wrong
The undeclared third party: a commercial model entered through a product feature toggle or a team subscription and was never admitted. No vendor assessment exists, no provenance terms were negotiated. The Layer 2 anti-pattern. Admission mistaken for authorization: a team treats board admission as permission to deploy, and the Layer 4 authorization never happens. Admitting the provider rather than the model: a blanket admission covering everything a provider offers, so a materially different model arrives under an assessment that did not contemplate it.
Related decisions
Downstream L4-VEN-01 licensing, L4-AUT-01 authorization, L4-REG-02 value-chain status where the model is later modified.
Upstream L6-04 sourcing posture and its concentration limit.
Related L2-01 integration pattern.
Instrument references
EU AI Act Article 25 addresses value-chain responsibility. NIST AI RMF MAP 3 and 4 address third-party components. ISO/IEC 42001 Annex A covers third-party AI components. None separates technical admission from contracting and authorization, which is why the three collapse in practice.
Correction
The maintainer answers corrections. There is no service level. Responses are best-effort and opportunistic within a reasonable time: a correction raised on a Monday is answered that week or sooner.