AI governance for portfolio launches is the operating model that defines where AI may be used, which data and systems it may touch, who reviews the result, how risk is evaluated, and what evidence must exist before release. The controls should be shared where risk is shared, while each company retains its own identity, permissions, source material, and accountable owner.

Begin with the use,
not the tool.

“Uses AI” is too broad to govern. Drafting alt text from approved product data is materially different from deciding credit eligibility, generating legal claims, changing production infrastructure, or answering customers with private account information.

Every use should have a short record: intended purpose, user and affected parties, model or service, permitted inputs, prohibited data, output destination, human owner, foreseeable failure, and stop condition. If the use cannot be described clearly, it is not ready to automate.

Automation does not transfer accountability.

The person or team responsible for the released outcome remains responsible when a model helped produce it.

Use risk tiers to keep
controls proportional.

LOW

Assistive

Internal ideation, summarization of approved non-sensitive material, formatting, and reversible drafts.

Named owner + ordinary review
MEDIUM

Published

Customer-facing copy, recommendations, generated media, code, or analysis that can affect trust or operation.

Source check + qualified human approval
HIGH

Consequential

Decisions or actions affecting rights, safety, money, identity, access, regulated claims, or sensitive personal data.

Specialist review + formal controls; prohibit when risk cannot be bounded

The NIST AI Risk Management Framework organizes risk work around Govern, Map, Measure, and Manage. That structure is useful because it connects policy and ownership to context, evaluation, and ongoing response. NIST's Generative AI Profile extends the framework with risks and actions specific to generative systems.

Protect portfolio
boundaries.

A multi-company portfolio creates a specific risk: shared tooling can quietly collapse boundaries that the brands, contracts, or data architecture require. Convenience is not permission to reuse one company's private content, customer information, credentials, analytics, or strategic material for another.

  • Keep credentials and provider secrets in approved server-side systems, never prompts or public code.
  • Identify the source and usage rights of input text, data, imagery, and code.
  • Separate company workspaces, repositories, access groups, and production environments.
  • Do not use sensitive or customer data unless the use is authorized, necessary, protected, and covered by the relevant provider terms.
  • Preserve the company-specific voice and facts instead of averaging the portfolio into one synthetic identity.

Evaluate the complete
system.

Model quality is only one part of the release. The surrounding system can fail through weak instructions, untrusted retrieval, prompt injection, excessive permissions, insecure output handling, stale facts, disclosure of sensitive information, or overreliance on confident language.

Evaluation should therefore cover the actual workflow. Test representative and difficult inputs, prohibited requests, source attribution, privacy boundaries, accessibility, output handling, fallback behavior, and the human review step. For software that uses language models, the OWASP Top 10 for LLM Applications provides a useful security-oriented threat catalogue; it does not replace product-specific threat modeling.

Require evidence before
public release.

  1. Purpose record

    The approved use, boundaries, affected audience, owner, and risk tier.

  2. Provenance record

    Models, prompts or instructions, data sources, important tool access, and rights constraints.

  3. Evaluation record

    Test cases, observed failures, mitigations, reviewer, and acceptance criteria.

  4. Release record

    Source revision, configuration, deployment, approval, customer-facing disclosure when appropriate, and rollback path.

  5. Response record

    Monitoring, incident owner, correction process, user feedback route, and conditions for suspension.

Evidence should be durable enough to reconstruct the decision without exposing secrets or personal data. The aim is not to archive every transient model thought. It is to preserve the information a qualified reviewer needs to understand what was authorized, tested, and released.

What good governance
looks like.

Good governance makes the safe path clear and the dangerous path difficult. Teams know which uses are pre-approved, when specialist review is required, where protected data may go, how to test a workflow, and who can stop it. Controls are reviewed as models, providers, laws, and portfolio risks change.

This field note is operational guidance, not legal or regulatory advice. High-consequence or regulated uses require review by qualified legal, privacy, security, accessibility, and domain specialists.

Primary references