Three integration sites that model-level AI audits leave exposed (2026)

Most AI audits start with the model. They score accuracy, probe refusal behavior, or inspect training data. Those checks matter, but a deployed system can still fail after every component has passed its own test: a data pipeline can change what the model sees, a user interface can turn a calibrated output into a bad decision, or two AI systems can interact in a way neither was tested to handle.

A new arXiv paper gives that gap a name: system integration auditing. Leah Davis, Dominic Martin, and AJung Moon’s scoping review, submitted on 5 August 2026, screens 4,259 records and retains 58 documents. Its contribution is not a new pass/fail score. It is a map of where audits can sit once the model is no longer the whole system. 1

The useful question is therefore not whether model-level evaluation should be abandoned. It is what that evaluation leaves unanswered once the model meets data, people, software, hardware, and other models.

The blind spot is between two passing components

Component evaluation asks whether one part behaves acceptably under a defined test. Integration evaluation asks whether the connection between parts preserves the properties the system is supposed to have.

That distinction sounds small but changes the unit of analysis. A model may produce technically valid outputs while the surrounding workflow presents them without the context a user needs. A deployment may meet a latency target while a changed upstream data source invalidates the assumptions under which the model was tested. A pair of agents may each follow its own policy while their interaction creates an unexamined loop. These are not claims that every deployment fails this way; they are the kinds of boundary questions the review says current audit practice often leaves underspecified. 1

The paper's strongest move is to replace the vague instruction to "consider context" with a set of dimensions that a team can actually scope.

Start with three integration sites

The review separates three places where an AI audit can look for integration risk. They are not three names for the same test: each expands the system boundary and changes the evidence a reviewer needs.

Integration site	What it connects	What the audit is trying to expose
Inter-component integration	Parts of one pipeline: data or input, model, output, and user interaction	Whether assumptions survive as information moves from one component to the next
System-environment integration	One AI system and the external workflow or setting in which it operates	Whether the system behaves acceptably when real users, procedures, institutions, or physical conditions enter the loop
Multi-system integration	Two or more AI systems and the boundary between them	Whether combined behavior creates dependencies, conflicts, or responsibility gaps that isolated tests cannot see

Inter-component audits are the most common and the most granular in the paper's corpus. System-environment audits treat the AI system more holistically, while multi-system audits have the broadest scope. A model benchmark can contribute evidence to the first site, but it becomes an integration test only when it tests the handoff or dependency—not merely the model in isolation. 1

The three sites sit on top of six elements the paper tracks across the literature: data/input, model, output, user interaction, deployment, and ecosystem. This gives an audit team two questions before it chooses a metric: which boundary is under review, and which elements participate in it?

A taxonomy is useful only if it changes the audit question

The paper adds two layers that stop the taxonomy from becoming a list of boxes.

The first is quality—what the audit is judging:

Compatibility: do the connected parts work together under the assumptions they share?
Completeness: does the evidence cover the relevant system, dependencies, and operating conditions rather than one convenient component?
Oversight: can people identify, question, and act on what happens across the boundary?

The second is function—what the audit is for:

Risk exploration: find possible failure modes or dependencies.
Risk determination: assess their severity or likelihood.
Coordination: align the people and organizations that control different parts.
Procedural regularity: check whether the audit follows a repeatable process.

That distinction matters in practice. A team can perform risk exploration without having enough evidence to determine risk. It can measure compatibility without establishing oversight. It can produce a technically sound report that no upstream provider or downstream operator is required to act on. The review's four functions make those gaps visible instead of treating "audit" as a single activity. 1

What the 58-document corpus says about maturity

The review uses the PRISMA-ScR framework and searches Scopus, IEEE Xplore, ProQuest, Web of Science, EBSCOhost, and WorldCat. The search was conducted in mid- to late November 2024. After duplicate and retraction screening, three reviewers handled title and abstract screening; their inter-coder agreement for the first 50 documents was 82%. The final 58 documents were coded qualitatively in ATLAS.ti, with one-third independently coded by all reviewers. 1

The distribution is more revealing than the total:

Signal in the corpus	Result	What it permits us to say
Records screened	4,259	The review is broad enough to map a scattered vocabulary, not just a handful of examples
Documents included	58	The retained literature is selective; the numbers describe this review's corpus, not the whole field
Documents that propose or conceptualize an audit	65.5%	The field is still designing audit approaches more often than reporting implemented ones
Earliest included publication	2019	AI-specific integration auditing is recent in this corpus
Largest publication share	2024, 29.3%	Attention accelerated before the review was written
Purely algorithmic systems	82.8%	Most work still stops closer to the algorithm than to the full deployment environment
Largest application area	Healthcare, 34.5%	The literature is concentrated rather than evenly distributed across domains
Second-largest application area	Hiring, 12.1%	Hiring is visible, but it does not represent the field as a whole

These figures support a restrained conclusion. The field has enough material to justify a taxonomy, but not enough implemented evidence to justify treating integration auditing as settled practice. The dominance of proposals is not a defect by itself; it tells a builder how much confidence to place in any checklist derived from the literature. 1

The three sites trade coverage for evidence burden

The sites are complementary, but they are not equally easy to audit.

Approach	What it buys	What it makes harder
Inter-component	A narrow boundary that can be traced and tested in detail	It can miss workflow, institutional, and environmental effects outside the pipeline
System-environment	A view of how the AI behaves inside an actual use setting	The setting is harder to reproduce, and evidence depends on users and operators outside the model team
Multi-system	The widest view of dependencies and emergent interactions	Responsibility, access to evidence, and causal attribution become much harder to assign

This is why one universal "integration score" would be misleading. A score that summarizes a model-to-output handoff cannot stand in for evidence about a clinical workflow or a network of agents. The review instead compares audits by the site, elements, actors, qualities, outputs, functions, system type, and application area involved. It also asks whether the audit meets traditional expectations of independence, systematic process, and system-level evidence. 1

For a product team, the practical translation is simple: do not ask only "Which test should we run?" Ask "Which boundary are we trying to make trustworthy, and who can change what happens on the other side of it?"

A short history of the boundary problem

The review places AI integration auditing against older safety-critical practices. Aerospace, medical-device manufacturing, and military software have long treated the interaction among components, suppliers, procedures, and operators as an object of assurance. The paper uses those regimes—and the Boeing 737 MAX 8 crashes as a motivating example—to show why a part-by-part view can miss a system-level failure. It does not claim that AI already has equivalent standards or institutional oversight. 1

The AI literature in this review starts in 2019, grows to its largest share in 2024, and remains heavily proposal-driven. That timeline is less a story of a finished discipline than of a field borrowing a mature question—how connected parts behave together—while still deciding what counts as evidence in an AI deployment. 1

A builder's audit plan derived from the paper

The taxonomy becomes actionable when it is used to scope a review before anyone chooses benchmarks.

Draw the system boundary. Include the data source, model, output path, user interaction, deployment stack, and ecosystem dependencies that can change the result.
Name the integration site. Decide whether the review concerns a handoff inside one pipeline, a system meeting its environment, or multiple AI systems interacting.
List the actors and evidence owners. Record who can alter each element, who can inspect it, and whether the proposed auditor is independent enough for the question.
Choose the quality being tested. State whether the immediate concern is compatibility, completeness, oversight, or more than one of them.
State the audit function. Separate finding possible risks from determining them, coordinating responsibility, and checking procedural regularity.
Define the output before the test. A report, escalation, change gate, or evidence package answers a different governance need. A test without an expected decision path is only a measurement.

The list is an interpretation of the review's framework, not a certification scheme. Its value is that it forces a team to say what a model score cannot say: which dependencies matter, which people hold the missing evidence, and what must happen when the boundary does not hold. 1

Where the paper stops

The paper is a scoping review, and its limits are part of its result. Its database search happened in November 2024, so it maps a literature snapshot rather than every newer practice. Its corpus is dominated by proposed approaches, not outcome studies that compare audit methods or show that one prevents failures. The review also records practical barriers: limited access to information, resources, and technical evidence; dependence on upstream providers and system integrators; and unclear rules about where audits should happen, who should participate, and what they should evaluate. 1

That leaves a clear reading decision. Read this paper if you need a vocabulary for auditing the boundary around an AI system, or if your current review stops at model behavior. Do not read it expecting validated thresholds, a universal independence rule, or proof that one integration method works best. The paper supplies the map; the engineering and governance work of turning that map into repeatable assurance is still open.

Read the full paper: "A Chain Is Only as Strong as Its Weakest Link: A Scoping Review of System Integration Audits in AI"

References

1
Davis, Martin & Moon, "A Chain Is Only as Strong as Its Weakest Link"
arxiv.org