Part 1 made the distinction: growth adds possibility, but integration makes that possibility usable.

The practical problem is visibility. Unfinished integration work is usually spread across contracts, project plans, customer records, identity systems, configuration data, service tickets, spreadsheets, runbooks, architecture diagrams, and the experience of people who have been quietly holding the seams together.

I would not ask AI to “integrate the company.” That gives a broad system an undefined objective and far too much implied authority.

I use AI for a narrower job: help the right people find, compare, and organize evidence quickly enough to make better decisions. Then I use Business Intelligence to show whether those decisions improved the customer outcome, reduced risk, and actually removed work.

Read Part 1: Growth Is Not Integration

Start with one integration question

The first question should be specific enough to have an owner and an observable result.

For example:

Which inherited systems, identities, vendors, and support paths still participate in delivering this service, and which of them lack a current owner, approved access, or documented disposition?

That question is useful because it does not assume that everything old should be removed. It allows five legitimate outcomes: preserve, connect, consolidate, isolate, or retire.

It also defines a boundary. The review is about one service or customer journey, not every document the combined company has ever created.

Before any model sees content, I identify the decision owner, approved reviewers, permitted sources, data classifications, retention rules, and actions that remain off limits. The first pass is read-only. AI cannot alter an identity, close a contract, retire a system, merge a record, send customer communication, or make a production change.

A prompt is not that control. The access limit must exist in the retrieval, identity, and tool layers before the prompt runs.

Build the evidence register before the recommendation

The first output is not an answer. It is a register of evidence.

For each relevant item, I want the model to extract or compare:

  • What the item is and which service or outcome depends on it.
  • The source, source owner, location, effective date, and confidence in the match.
  • The authoritative customer, contract, asset, identity, or service identifier.
  • Current business and technical owners.
  • Access level, data classification, vendor relationship, and support path.
  • Dependencies, exceptions, renewal dates, and stated retirement plans.
  • Contradictions, missing evidence, and information the reviewer was not authorized to retrieve.

The last three categories matter. A useful agent needs to say, “These two records conflict,” “I do not have evidence,” and “This source is outside the approved boundary.” A confident guess is not a completed integration record.

NIST's AI Risk Management Framework calls for the task, context, human-oversight roles, data suitability, and third-party components of an AI system to be defined and documented. That is the right shape for this work. The model is part of a governed review, not an unsupervised decision maker. (NIST AI RMF)

This is the first prompt I would use after the system has supplied an authorized evidence set:

Review only the supplied evidence for the named service. Create an integration register of systems, identities, vendors, support paths, contracts, data definitions, and responsible owners. Cite the source and effective date for every finding. Separate confirmed facts, contradictions, missing evidence, and restricted evidence. Do not infer ownership, authorization, equivalence, or retirement status. Do not recommend or perform a change.

The wording helps, but the surrounding controls do the real security work.

Reconcile meaning before combining the data

AI can find records that look alike. It should not silently declare them the same.

Two customer names may refer to one legal entity, two divisions, a reseller relationship, or unrelated organizations with similar names. Two products may share a label while carrying different support commitments. Two “administrator” groups may have very different authority. Two service-level reports may start and stop their clocks at different events.

I ask AI to propose candidate relationships and explain the evidence for each one. The data owner or process owner decides whether the relationship is real.

Compare the reviewed records using approved identifiers and documented crosswalks. For each proposed match, show the supporting and conflicting evidence. Mark any relationship that requires a person to decide. Do not merge records or choose an authoritative source.

This is where experienced human judgment changes the value of the output. Someone has to recognize that an old product name carries a contractual promise, that a rarely used monitoring path is the only one covering a critical customer, or that a local workflow exists because a broader process never supported the exception.

AI makes the pile easier to read. It does not decide which promises matter.

Turn the findings into an integration-debt map

After owners confirm the evidence and reconcile the important definitions, I group the remaining work by customer effect, security exposure, financial cost, operational dependency, and effort to resolve.

The map is deliberately more useful than a list of duplicates.

For each item, it shows:

  • Treatment: preserve, connect, consolidate, isolate, or retire.
  • Reason: customer value, regulatory need, technical dependency, security boundary, cost, or temporary transition.
  • Owner: one accountable person, with the teams needed to complete it.
  • Dependency: what must happen first and what could fail if the item changes.
  • Evidence of completion: the test, record, approval, or customer outcome that proves the work is done.
  • Risk while open: including customer, security, financial, and business-continuity exposure.
  • Capacity: the people, time, and specialist knowledge required.

This is where AI can surface patterns that are difficult to see across hundreds or thousands of records: one small specialist group appearing in many critical paths, the same manual reconciliation repeated across services, inherited remote-access tools without current sponsorship, or renewal dates that create a practical migration deadline.

It can also help simulate sequencing. If a platform is retired first, which services lose monitoring? If identities are consolidated before customer records are reconciled, where could access attach to the wrong account? If another acquisition closes during the same quarter, which reviewers and engineers become the shared constraint?

Those are planning scenarios, not predictions. People review the assumptions, and leadership owns the tradeoff.

Give the AI an identity, a limit, and a trail

An agent that can retrieve evidence or call tools needs its own identity. Its authority should be attributable, limited to the task, time-bounded, and no broader than the person and process that delegated it.

NIST's 2026 work on software and AI agent identity highlights identification, authorization, auditing, non-repudiation, and prompt-injection controls as active enterprise concerns. The technology is moving quickly, but “the agent did it” is not an acceptable ownership model. (NIST NCCoE)

For an integration review, I want:

  • A service identity created for the specific workflow, not a shared administrator account.
  • Query-time authorization against the current source permissions.
  • Read-only access for discovery and comparison.
  • No production tools in the first stage.
  • Source references, denied-source events, model and prompt versions, reviewer corrections, approvals, and final decisions in the audit trail.
  • Human approval and a fresh authorization check before any consequential action.
  • Expiration or revocation when the review ends.

Retrieved content is evidence, not instruction. A document, ticket, or web page can contain text that redirects a model. The system must restrict what the agent can retrieve and do even if the model follows a malicious instruction. NIST's Generative AI Profile recommends tracking provenance, defining human oversight, testing system behavior, and managing risks across the complete AI lifecycle. (NIST AI 600-1)

I would stop the workflow for unauthorized retrieval, unexplained record matching, a broader credential than the task requires, an action without an owner, or a change without rollback and acceptance evidence.

Use Business Intelligence to prove that the work disappeared

Closing an integration task is not the same as removing its effect.

The BI layer should connect the integration-debt register to real outcomes. Depending on the service, I would track:

  • Percentage of critical assets, identities, data stores, and vendors reconciled to current owners.
  • Privileged and remote-access paths validated, removed, or isolated.
  • Legacy platforms with a funded and tested treatment decision.
  • Manual reconciliations and repeated data correction.
  • Transfers, reopened work, missed commitments, and repeated customer explanations at legacy handoffs.
  • Services sold outside their validated delivery or support path.
  • Time that critical integration items remain blocked by unavailable specialist capacity.
  • Exceptions that were reopened after being reported complete.

The denominator must remain visible. “Ninety percent reconciled” means little if nobody can explain what population was measured or what remains outside the inventory.

The definitions must be versioned too. If “resolved,” “active,” or “integrated” changes halfway through the program, the dashboard should disclose the change instead of drawing one smooth trend across two meanings.

GAO's review of private-sector cloud practices found that companies reported challenges documenting application dependencies, shutting down legacy systems, and maintaining accurate IT inventories. It also found examples of companies using systematic migration programs, automation, templates, dependency analysis, and recurring usage reports. The setting was cloud adoption, but the operational lesson transfers: inventory, dependencies, automation, and measurement have to work together. (GAO-25-106369)

Where I help

This work sits between disciplines, which is why it is often difficult to assign.

It needs enough architecture to understand dependencies, enough Customer Experience to follow what the customer actually feels, enough security to limit access and challenge unsafe shortcuts, enough automation to reduce repeated manual work, and enough Business Intelligence to show whether the change produced the intended result.

That is the kind of bridge I build.

I help leadership select the decision worth examining, help specialists define the evidence and boundaries, use AI to accelerate the cross-reading and comparison, and turn the reviewed findings into an integration map people can own. Then I connect the map to measures that reveal whether the customer journey, risk, and cost improved.

The people who know the acquired capabilities still make the consequential decisions. AI gives them a faster way to see the same problem together.

The goal is not an autonomous integration program. It is a better-informed organization that can finish more of the work it starts... before customers, auditors, or attackers discover the gaps first.

Which integration question would become easier if the right people could finally see the same evidence?