One AI program across a portfolio does not mean one shared knowledge pool

Standardize the method before the data

A central team can reuse a source-register format, test harness and release checklist without granting every portfolio employee access to every company's information. Begin by separating the governance pattern from the knowledge content. Ownership of a portfolio does not automatically establish a lawful or appropriate audience for each source.

Choose one company, one question family and one employee audience. Record the local procedure owner, system owner and support route. Even apparently ordinary remote-access instructions can differ after an acquisition. A generic shared answer can be technically plausible and still wrong for that company's devices or operating policy.

Create a company-specific release record

This separation helps central teams compare progress without pretending the companies have identical systems. Do not rank them by prompt volume or copied policy count. Compare whether a bounded employee task is supported and governed, with the local differences visible.

Illustrative editorial photograph, not a customer result.

Test cross-company requests deliberately

Use harmless synthetic material for Company A and Company B in a permitted evaluation environment. Ask each audience for the other company's information. Inspect denials, source links, retrieval behavior and cached outputs under the actual implementation. Shared branding or similar document titles must not become a shortcut around authorization.

Then ask a question that requires identifying the company. The system should clarify if the user's context does not establish it. It should not silently choose the most common source. Keep applicability and permission as separate review dimensions: a permitted document can still be the wrong company's instruction.

Preserve local authority after acquisition

An acquisition does not instantly replace every approved local rule with a central standard. Name who decides when a procedure changes and which audience can use it before the change. Record effective versions, transitional exceptions and the owner who resolves conflicts. A migration project should not let an assistant improvise policy harmonization.

Keep support responsibilities explicit. If a local guide cannot answer, the employee needs the correct local owner, not a generic central mailbox nobody monitors. Check the route with the receiving team and record what information it needs without copying restricted records into a general worksheet.

Expand from evidence, not similarity

When the first company passes, reuse the method for the second and test its real source and audience differences. Similar tools do not prove identical permissions. Similar procedures do not prove identical applicability. Estimate maintenance and connection work separately rather than treating rollout as copying a prompt.

Put this to work this week

Choose two portfolio companies with genuinely different approved procedures. Prepare harmless company-specific test guides and expected denials. Ask the central team to describe the reusable governance method and each local owner to describe the source and support route. Resolve the difference before configuration. Record company-specific acceptance results separately. This makes the comparison useful without flattening local rules or treating shared ownership as permission to combine information.

Use the Company AI Source Register and the permission-drift guide. OWASP's RAG guidance discusses isolation in retrieval systems; these planning records do not themselves enforce it. Request a portfolio-focused demo around one company and a synthetic cross-company denial case. SimplSolutions can scope a repeatable intelligence-layer method while preserving each company's approved sources, boundaries and accountable owners.