Part 1 asked what should survive an acquisition. The practical follow-up is how to uncover enough evidence to make that choice without turning the project into a year-long inventory exercise.
Start with Part 1: What Should Survive an Acquisition?
When someone asks me to help with this, I do not begin with, "Analyze these two companies, and tell us what to consolidate." The question is too large, it points the model toward an answer, and nobody has established whether its source material is complete or authoritative.
I begin with one real decision. Should two customer-support entitlement processes become one? Should two identity platforms interoperate for a while? Can a reporting system be retired without losing the definition behind a measure? A question at that scale gives leadership something useful to decide, and it gives the people closest to the work a fair chance to show what the diagram missed.
This is the kind of junction where I am most useful. I can translate among leadership's need for a choice, engineering's need for dependency detail, security's need for controlled access, Customer Experience's need to protect customer outcomes, and Business Intelligence's need for trustworthy measures. AI makes the discovery faster. I turn what it finds into work that people can safely carry out.
Begin with a decision that fits on one page
Take customer-support entitlement as an example. One company may decide who receives support from a contract record. The other may rely on a combination of location, product, subscription status, and named contacts. They can look like duplicate processes from a distance. Up close, each may carry customer promises, billing rules, escalation paths, and recovery knowledge.
Before I bring AI into that discussion, I write down the decision, the people authorized to make it, the systems and documents allowed for the first review, and the actions that remain off limits. The first pass should be read-only. It should not merge a record, change an entitlement, disable an account, or update a production route.
I would start with a prompt like this:
Prompt 1: Build the evidence table
"Using only the approved sources listed below, identify what each customer-support entitlement process does today. For every claim, provide the source, location, effective date, source owner if known, and the exact supporting text or field. Separate confirmed facts, likely matches, contradictions, and missing information. Do not recommend consolidation or retirement. Do not fill a gap with an assumption."
That asks for evidence before an opinion and creates something people can correct. A table of claims, sources, contradictions, and open questions gives the contract owner, support lead, engineer, security reviewer, and data owner something specific to challenge.
The source set depends on the decision. It might include contract language, architecture diagrams, ticket-routing rules, identity roles, report definitions, runbooks, and validated interviews. It should not automatically include every file the combined organization owns.
Make the answer traceable and permission-aware
The model should point back to the evidence behind every important statement. If two fields supposedly have the same meaning, I want the definitions, effective dates, and owners. If a system can supposedly be retired, I want the dependencies it checked and the sources it could not access.
NIST's Generative AI Profile recommends recording data provenance, model versions, access modes, human-oversight roles, and special handling for personal, privileged, proprietary, and sensitive data. It also recommends verifying sources and citations and checking that retrieval data is grounded. Those are voluntary risk-management recommendations, but they are a sensible minimum for this use. (NIST AI 600-1)
Access control matters as much as citation. New ownership does not mean every employee, model, or integration service should see every contract, employee record, customer secret, or security finding. NIST's zero-trust guidance says trust should not be granted solely because of network location or ownership, and that authentication and authorization occur before access to a resource is established. (NIST SP 800-207)
I apply that principle to retrieval. The AI should receive only the evidence the requesting person is authorized to use. Source permissions should carry into the index and the answer. A missing permission should produce a visible gap, not a hidden search through a more sensitive repository.
There is another reason to keep the boundary tight. NIST identifies prompt injection and data poisoning as risks to generative AI systems, including indirect prompt injection hidden inside material the system retrieves. (NIST AI 600-1) A document is evidence, not an instruction to the AI. Retrieved text should never be allowed to override system rules, expand its own access, or trigger a production action.
Make the model argue against an easy answer
"Duplicate" is one of the most expensive words in an integration if nobody tests it.
Two systems may share a product name and many customers. One may still be the record for legal account ownership, while the other controls site-level support entitlement. Two reports may both show monthly recurring revenue, while one includes contracts and the other only activated subscriptions. Similar labels are clues, not proof of equivalence.
This is where I ask the model to challenge its own first impression:
Prompt 2: Test the duplicate claim
"For each apparent duplicate, make the strongest evidence-based case that the two capabilities are equivalent, and then make the strongest evidence-based case that they are not. Compare business purpose, customer promise, data meaning, source authority, security control, failure behavior, recovery path, owner, and effective date. List the evidence that would resolve each remaining disagreement."
That turns a quick match into a review question. People from both organizations can accept it, reject it, or explain the exception. Their decision is recorded with the evidence and reason. The model's confidence score is not approval.
Part 1 described five possible treatments: standardize, interoperate, preserve, coexist for a while, or retire. AI can help compare the evidence for those choices. The accountable people choose one.
Turn the approved choice into an integration map
Once people have approved the treatment, I use AI again for a different job. Now it can help assemble the work around the decision.
Prompt 3: Draft the integration map
"The approved treatment for this capability is [treatment], based on the attached decision record. Draft an integration map that shows prerequisites, dependencies, accountable owners, sequence, customer impact, security controls, data-definition changes, acceptance evidence, rollback conditions, and review dates. Mark every missing owner or unsupported dependency as unresolved. Do not invent an owner, deadline, approval, or technical relationship."
For temporary coexistence, the map should show which customers remain on each path, how identities cross the boundary, who reconciles exceptions, and what must be true before retirement. A retirement decision should trace data retention, contract obligations, access removal, support communications, and recovery. Interoperability needs an authority on both sides and a plan for failure.
AI is good at keeping this material connected. It can flag a retirement date that conflicts with a contract, an identity provider still named in a recovery procedure, or a task with no owner. Later source changes can bring affected assumptions back for review.
I still want the normal architecture, security, change, and business-acceptance processes to authorize production work. The map prepares those decisions. It does not bypass them.
My role is part architect, part investigator, and part bridge builder. I help the person who knows the odd exception explain it in terms leadership can evaluate. I turn the business choice into technical acceptance criteria, help security set limits, and build or guide the automation that keeps the record current.
Use Business Intelligence to test the result
An integration map explains what should happen. Business Intelligence helps show whether it did.
The measures have to be agreed upon before they are combined. If the two organizations define "customer," "resolved ticket," or "recurring revenue" differently, a single dashboard can create false confidence. I want the source, formula, owner, effective date, and known difference behind each shared measure.
Prompt 4: Compare the result with the baseline
"Using only approved measures whose definitions and sources are included, compare the baseline with the current state for this capability. Show changes in customer-impact incidents, support transfers, entitlement errors, authentication failures, recovery time, manual reconciliation, and operating cost. Identify any changed definition, missing period, or source conflict before calculating a trend. Do not combine measures that have not been reconciled."
The exact measures will change with the decision. The discipline should not. A faster migration is not a success if customers lose access. A lower platform count is not a success if manual reconciliation moves into spreadsheets. A cleaner identity directory is not a success if the recovery account no longer works when it is needed.
NIST Cybersecurity Framework 2.0 connects executive risk decisions, accountable roles, implementation, and measures that let leaders adjust strategy. It treats data, hardware, software, systems, services, and people as assets that enable business purposes. The dashboard should measure the capability and its risk, not just completed technical tasks. (NIST Cybersecurity Framework 2.0)
If I were starting tomorrow, I would choose one pending decision, a few authoritative sources, and reviewers from both organizations. First comes the evidence table, then the challenged duplicate analysis. After people resolve those questions, I draft the integration map and define the Business Intelligence measures.
AI can remove a great deal of searching, comparison, and documentation. It can also make an unsupported answer sound finished. Useful results need approved evidence, visible gaps, preserved permissions, named decision makers, and measures tied to the customer and business outcome.
This is work I enjoy because it brings people together around something better than opinion. The engineer, support specialist, analyst, security reviewer, and executive each see a different part of the truth. My job is to help them build a shared picture, use AI where it genuinely saves time, and move forward without erasing what still matters.
Also available on LinkedIn.