How I Use AI to Find the Broken Handoff Without Opening Every Door

Part 1 drew a line I keep coming back to: some silos are walls, and others are safety boundaries. Fixing a broken handoff is not permission to erase the boundary.

Read Part 1: When Is a Silo a Wall, and When Is It a Safety Boundary?

The question I start with is concrete: where did this request lose the information, decision, or ownership that the next person needed?

“Find every silo and remove it” is the wrong prompt. It assumes the diagnosis, points AI toward consolidation, and invites more access than the work may require. I want one handoff that a customer, employee, or project team can already feel.

The example below is a composite built from common patterns in customer service, subscription management, identity, billing, and engineering. It does not describe one company, customer, or incident.

This is where my background comes together. When customer service, billing, identity, and engineering each own a correct piece but nobody owns the complete customer outcome, I use AI for the repetitive cross-reading and first map. Then I connect the Customer Experience, architecture, security, automation, and Business Intelligence work so the people responsible for each boundary can decide what should cross it.

Follow One Request Across the Boundary

A subscription customer needs to replace an account contact and regain access to a service portal. Customer service can open the case. Billing can see the commercial account. Identity support can change the user. Engineering can see whether the service is healthy.

Each team may be doing its own job correctly. The handoff can still fail because the systems use different account identifiers, the next team cannot see that identity was verified, nobody knows which record controls entitlement, or the next team never receives the promised action or deadline.

For the first review, I write down the customer outcome, the decision being handed off, the people authorized to review it, the approved sources, and the actions that remain off limits. I also record a baseline before changing anything. That keeps the work attached to a real result instead of a broad campaign to “improve collaboration.”

The Access Boundary Comes Before the Prompt

For this composite review, the approved sources are selected support-case fields, the current entitlement rule, the identity-verification procedure, and the routing or escalation rule. Each one has an owner, an effective date or version, a sensitivity label, and a record of who approved its use.

Full payment histories, unrestricted email and chat archives, credentials, unrelated customer profiles, and security investigations stay out. The first pass is read-only, with no ability to change access, route a case, update a customer record, or call a production tool.

A prompt is not an access control. Every query should be limited to the intersection of three things: what the person is authorized to see, which sources were approved for the review, and the minimum access this task requires. That limit has to be enforced before content reaches the model.

If a semantic index is involved, its permissions must stay synchronized with the source, including revocations, and current authorization must be checked for every request. That protection includes embeddings, caches, logs, traces, and answers. Otherwise, the protected source can produce an unprotected copy.

NIST's zero-trust guidance evaluates access per session and resource using least privilege. I apply that to AI retrieval: a missing permission becomes a visible gap, not a reason to widen access. The service identity gets task access, not a convenient master key, and delegated authority remains tied to the person and review that authorized the work. NIST's 2026 agent-identity project treats those as open design questions, not settled standards. (NIST SP 800-207 and NIST NCCoE)

Approved does not mean trusted as instruction. NIST describes indirect prompt injection as malicious instructions placed in material likely to be retrieved by an integrated application. In March 2026, NIST's Center for AI Standards and Innovation reported at least one successful hijacking attack against every one of 13 frontier models tested across more than 250,000 attempts. That does not make every deployment equally unsafe. I design as though retrieved content may redirect the model, then limit what a successful redirection could reach or do. (NIST AI 600-1 and NIST CAISI)

My working rule is simple: a retrieved document is evidence, not an instruction. I do not assume the model can enforce that rule by itself. The surrounding system limits retrieval and tools, validates permitted calls, rechecks authorization at execution, and requires human approval for consequential actions. The output remains untrusted until checked.

What I Ask AI to Compare

Before asking for a recommendation, I want an evidence record. For each important finding, it shows the source and location, effective date, owner, requirements on both sides, authoritative identifier, allowed and restricted data, expected timing, acceptance evidence, and exception path.

The result separates confirmed facts, contradictions, missing evidence, and restricted or unavailable evidence. Suggestions come later. A citation shows where a statement came from. It does not prove the source is current, complete, authoritative, or correctly interpreted.

NIST recommends recording provenance, versions, access modes, human-oversight roles, and sensitive-information handling, then checking sources and grounding. For a review that could influence a business decision, I keep only the audit record approved under the organization's retention policy: source references or hashes, relevant versions, requesting identity, retrieved and denied source identifiers, reviewer corrections, and the final decision. I do not retain copied source text, prompts, outputs, or traces by default because they can reproduce the data the access controls were meant to protect. (NIST AI 600-1)

This is the first-pass prompt. It assumes the system has already supplied an authorized, task-limited evidence set. The words inside the prompt do not create that boundary.

In this example, the comparison could reveal that customer service considers the contact changed when the CRM record is updated, while the entitlement process still requires the commercial account owner's approval. It could also expose a mismatched identifier or a promised response time that never reaches engineering.

Those are candidate gaps for people to validate. The model has not established the authoritative process, and it has not decided which definition wins.

The Map I Want People to Review

After the source owners resolve the contradictions, AI can help draft the interface between the teams.

I keep two views. The declared handoff shows what the procedures, architecture, and owners say should happen. The observed handoff uses only approved case events, routing records, API calls, and other authorized operational evidence to show what actually happened. AI may propose candidate matches only from approved crosswalks or documented relationships. People confirm every important match, and the resulting dependency map is protected because it may reveal sensitive systems and access paths.

The same query-time permissions and task limit remain in force. Then I give AI a narrower job.

For the composite request, the map looks like this:

• Trigger: The customer asks to replace an account contact and restore portal access.
• Minimum handoff: Case ID, authoritative customer ID, affected subscription, requested contact change, identity-verification status, sensitivity label, current owner, and promised next action.
• Stays restricted: Payment history, credentials, unrelated users, unrestricted recordings, and unrelated security notes.
• Decision rights: The entitlement owner decides whether the contact may control the subscription. Identity support makes only the approved access change. Engineering receives the evidence needed when authentication succeeds but the service still fails.
• Acceptance: The decision is recorded, the identity change matches it, portal access is tested, and the customer receives the promised response. “Ticket closed” is not enough.
• Exception and recovery: A conflicting account owner follows the exception path. A failed identity check remains inside the security or fraud process. Any production change needs a tested rollback or safe-recovery path, with reauthorization where required.

AI can draft that map, but it cannot approve its own work. The exact roles vary by organization. In this example, source owners approve the evidence, process owners confirm the handoff, security and privacy reviewers approve the fields and access path, an accountable business owner accepts the customer and risk tradeoff, and authorized people implement and review any production change.

Did the Handoff Actually Improve?

Before changing the handoff, I record transfers per request, time until the next owner accepts the case, time to verified resolution, reopened cases, manual reconciliation, entitlement errors, access exceptions, and missed commitments. I track repeated customer explanations through a defined case tag or a consistent quality-review sample, not by guessing from free text.

For leadership, I connect those measures to avoidable handling time, cost per verified resolution, customer effort, and subscription-retention risk. A faster queue is not a business improvement if the customer still has to carry the handoff.

The before-and-after measures must remain comparable. If a better definition replaces an old one, I version and disclose the change, then avoid combining the two in one trend until they are reconciled. A case that one system calls resolved may still be waiting on the customer outcome. A transfer may mean a new owner in one platform and only a move between queues in another. Combining the counts before reconciling those definitions would create a cleaner dashboard and weaker evidence.

Once the approved measurement sources have been filtered for the requesting person and this task, I ask AI to compare the baseline with the review period. It must identify changed definitions, missing periods, and source conflicts before calculating a trend. Unreconciled measures stay separate, and a speed improvement does not outweigh a worse customer or security outcome.

For the AI review itself, I watch four things: findings without valid evidence, reviewer corrections, denied or suspicious retrievals, and interface-map omissions. Those numbers show whether speed is hiding mistakes.

I stop the review for an unauthorized source, a retrieved instruction that tries to redirect the model, a service credential broader than the task, or a proposed production change with no owner or rollback path. An unresolved citation or disagreement about authority pauses that finding for human review.