Elicitation Gap

What the elicitation gap represents

The elicitation gap is not a property of the model alone. It is the space between latent capability and observable output, shaped by how the system is prompted, what the interface permits, and which safety or policy controls limit disclosure. For evaluators, that means apparent weakness can reflect access limits rather than true lack of knowledge.

Because the gap is defined by what can be surfaced under a specific testing setup, it is best treated as an assessment measure rather than a fixed attribute. A narrow gap may indicate that the evaluator’s prompts are effective, while a wider gap can mean the system is withholding useful behaviour, refusing to comply, or simply not being tested in a way that reaches the relevant capability.

Why the elicitation gap matters in model assessment

The concept matters because evaluation results can be misleading when teams assume observed behaviour equals total capability. A model may appear safer, less capable, or less useful than it really is if the evaluation environment suppresses outputs through guardrails, formatting constraints, tool restrictions, or incomplete prompt coverage. That creates risk in both directions: underestimating capability and overestimating safety.

In practice, the gap is especially important when judging whether a system can reliably perform a task under stress, ambiguity, or adversarial prompting. If the evaluator cannot consistently elicit an action, refusal, or explanation, the assessment may be measuring the interaction design more than the underlying system behaviour.

What creates the gap

The gap usually emerges from a combination of factors. Prompt phrasing can fail to reach the relevant internal representation, interface design can constrain the form of the answer, and safety layers can suppress outputs that would otherwise reveal capability. In agentic settings, tool permissions, routing rules, and output policies can further reduce what is observable from the outside.

That means the same underlying system can produce very different assessment results depending on the test harness. A benchmark that uses narrow prompts, limited context, or rigid answer formats may record a large gap even when the model has the relevant knowledge. Conversely, a carefully designed probe can shrink the gap by making the requested behaviour easier to surface.

How to interpret it in evaluations

Assessments should treat the elicitation gap as evidence about observability, not a simple yes-or-no measure of ability. A low score may mean the evaluator has not found the right prompt pattern, not that the capability is absent. A high score may mean the system is easy to steer, not that it is broadly reliable or safe in real use.

That is why the most useful interpretation compares multiple prompts, interface conditions, and safety states. The goal is to understand how much behaviour is hidden, how much is genuinely unavailable, and how much changes when the evaluation method changes. For red teaming and capability testing, this distinction is often more important than any single output.

Risk and Threat Considerations

The main risk is mismeasurement. If organisations assume the visible output fully reflects model capability, they can miss latent behaviours that become available under different prompts, tool access, or workflow conditions. The same gap can also conceal unsafe tendencies during testing, creating a false sense of control.

Failure mechanism: An evaluator relies on an interface or prompt pattern that suppresses the behaviour being tested, so the system appears more constrained, less capable, or less risky than it really is. Adversaries may exploit the same mismatch by reshaping prompts or contexts to elicit behaviour that routine testing did not surface.

Impact: Security teams may underprice abuse paths, miss dangerous edge cases, or ship controls that only work in the test environment. In an agentic or tool-using system, that can translate into unexpected actions, hidden capability, or incomplete safety assurance once the system is placed in production.

Practitioner Guidance

What to watch for: Treat a persistent elicitation gap as a testing signal, not a conclusion. If the system behaves differently across prompts, interfaces, or safety settings, document those differences and separate true absence of capability from hidden or suppressed capability.

Practitioner note: Strong evaluations usually combine multiple prompt styles, boundary conditions, and red-team probes so the assessment can distinguish model knowledge from the evaluator’s ability to surface it. The most reliable result is often not a single score, but a map of where the system can and cannot be elicited.

Related resources from NHI Mgmt Group

• Why do AI agents create an attribution gap in IAM?
• Why does embedded AI in SaaS create a governance gap?
• Why do browser extensions create a governance gap for IAM teams?
• Why do endpoints create a Zero Trust governance gap?