Shared AI Infrastructure for Portfolio Companies Without Taking Their Data

For an investor, the useful question about AI for portfolio companies is not which model to buy. It is which shared infrastructure, memory standards and governance rules to offer, and which contents to leave with each company. A sound answer shares the plumbing (identity, logging, evaluation routines, review calendars) and keeps the substance (customer records, know-how, the memory an agent builds from each company's work) under that company's own ownership and approval rules.

Key takeaways

• Share the operating plumbing, not the company's data: access controls, logs, evaluation methods and review dates can be common across the portfolio.
• Define memory standards as shapes and rules that each company owns, so an agent can be set up in a new company without copying anything from the last one.
• Write governance once, with decision rights and review dates, then let each company add its own boundaries on top.
• Require every shared component to be exportable and removable, so no company is locked into a layer it cannot leave.
• Start with one role in one company, prove the success criterion, and only then extend the pattern to the next company.

What belongs in a shared layer and what stays local

A shared layer is the set of services that every company uses in the same way. Its value is consistency: the same way of granting access, the same log format, the same test method, and the same calendar for reviews. When these are common, an incident in one company can be read by the investor's team without learning a new system each time, and improvements to the method benefit everyone. The shared layer should be small enough to describe on a few pages.

• Identity and access: how people and agents sign in, which roles exist, and who approves a new tool connection.
• Observability: records of agent actions, tool calls and errors, written in a common format so incidents can be compared across companies.
• Evaluation routines: a shared test method and scoring rules, with each company supplying its own test cases from its own work.
• Review calendar: permission reviews and incident drills on dates the investor proposes and each company confirms.

What stays local is anything that describes the company itself. That includes customer records, prices, contracts, technical know-how, and the memory an agent accumulates from the company's conversations and documents. Each company should be able to name the owner of every store, and delete or export it without asking the investor for permission. If a shared component cannot satisfy that test, it belongs in the local column.

Which memory standards to offer portfolio companies

In this context, memory means what an agent keeps between sessions: notes about a customer, a decision log, a glossary of terms the company uses. Memory standards should govern the form of that information, not its content. A common schema gives every entry the same fields, so the investor can audit and support the agents without reading the sensitive material itself.

Many companies will be tempted to fine-tune a model on their documents. For most portfolio use cases, retrieval is the safer default, because the documents remain in a store the company controls and can be removed without retraining anything. Retrieval-based designs look up relevant material at the moment of a question, which also makes it easier to show where an answer came from. The standard should require that each indexed copy follows the same deletion rule as the original.

• Every memory entry names the document or conversation it came from.
• Every entry carries a sensitivity label set by the company, not by the platform vendor.
• Retention periods are written per category, and deletion is tested rather than assumed.
• Indexes and embeddings are treated as copies of company data, subject to the same retention and deletion rules.
• Export in an open, documented format is a condition of the standard, not an optional feature.

Governance rules that protect each company's data

Governance is where an investor's offer becomes credible or empty. The NIST AI Risk Management Framework organizes the work into governing, mapping, measuring and managing risk. A portfolio version can be much lighter than a large enterprise program, but it should keep the same logic: who decides, what is measured, and what is reviewed on a schedule. For a practical starting point, a lightweight charter with named decision rights is usually enough for a first round.

Authorization deserves particular care. OWASP's authorization guidance points toward checking permissions on each access, not once when a session begins. For agents, this means every tool call should be evaluated against the current role and the current approval state. Agents that read documents or web pages also face prompt injection, where instructions hidden in content try to redirect the agent. The rule is simple to state: content an agent reads is data, not a source of new permissions.

• A written decision right for each class of agent action: act alone, act after approval, or never act.
• Least privilege by default: an agent receives only the tools its one role requires.
• Authorization checked at the tool level on every call, not only at sign-in.
• Prompt injection treated as a known risk, with rules stating that instructions found inside documents or pages do not change permissions.
• A named owner at each company for every permission, reviewed on a date already in the calendar.
• An incident path that states who is alerted, who can pause the agent, and how the company receives its own logs.

A step-by-step plan for the first offer

The first offer should be narrow enough to finish and measure. The sequence below keeps the investor's role on standards and the company's role on its own data.

• Step one: Inventory repeated work across the portfolio. Look for functions that recur in several companies, such as support triage, monthly reporting or supplier follow-up.
• Step two: Write the shared standards once: identity, logging format, memory schema, evaluation method and review calendar. Keep the document short enough that a company leader will read it.
• Step three: Choose one pilot company and one role. Define the success criterion in a measure the company already tracks, and list the only tools the role needs.
• Step four: Have the company's own leader approve the data boundaries before any system is connected.
• Step five: Run the pilot with recorded evaluations and a permission review before anything expands. The stage gates in how to tell proof of concept, pilot and production apart help set those checks.
• Step six: Extend to a second company only after the first has passed a working export test and a working deletion test.

Illustrative scenario: three companies, one shared layer

Illustrative scenario, not a client case: an investor backs a logistics software company, a network of outpatient clinics and a specialty retailer. The investor offers all three the same identity model, log format, evaluation method and quarterly review calendar. Each company keeps its own memory store, its own customer records and its own approval rules.

The retailer decides that its agent may draft replies to customers but may not issue refunds, so refunds stay with a named staff member. The clinics keep patient records entirely outside the shared logs, and their logs record only the fact that a tool was called, not the content. When the logistics company later decides to leave the program, it exports its memory store and logs, and the shared copies are deleted within the window written in its agreement. The other two companies see no change, because nothing they own was ever stored in a place the logistics company controlled.

How a managed approach keeps the boundaries in place

Be Human designs and operates this kind of layer as a managed service. Each company receives an agent with its own identity, memory, channels, tools and permissions, and the shared components are maintained under written rules. Managed operations include monitoring, recurring evaluations, integration maintenance, permission reviews, incident response and controlled improvements that the company approves before they reach production. Changes follow a documented path, as described in how to request and approve changes to a managed AI agent. The first engagement defines one role, the memory and tools it needs, its approval boundaries and an observable success criterion, so the investor sees what is shared and what is local before the pattern grows. If you want to find the first task in one of your companies worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Should an investor hold the AI memory of its portfolio companies? No. The memory an agent builds from a company's work belongs to that company, and the investor's role is to set the standards for its format, retention, export and deletion. An investor who keeps copies for convenience takes on responsibility for data it does not need and creates a dependency that companies may reasonably resent. Standards that require export and deletion protect both sides.

Is a shared AI platform the same as shared company data? No. A shared platform provides common services such as identity, logging, evaluation methods and review schedules, while each company's data stays in stores it controls. The two should be separated in writing, so that a shared log format never quietly becomes a shared repository of customer records or know-how.

How do we stop one company's know-how from reaching another through a shared model? Use retrieval from company-controlled stores instead of training shared models on company documents, and keep each company's index separate. Apply least privilege so an agent in one company has no tool or path into another company's store. Review those connections on a fixed date, and test that the separation holds rather than assuming it.

What should an investor ask before offering AI infrastructure to a portfolio company? Ask who owns the data at each stage, what the company can export and delete, which actions require human approval, and who is alerted during an incident. Then ask for one measurable success criterion for a single role. If the answers are specific and written, the offer is ready to pilot. If they are vague, the work is not ready to scale.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.