How Do You Build an AI-Ready Operating Model Across a Multi-Venture Portfolio?

Summary

The steps

1. 1

   Audit Your Current Process Landscape

   Before any AI tool is evaluated, map the recurring processes across every venture in the portfolio. A process qualifies for this map if it runs at least weekly, involves a decision or transformation of information, and currently requires human attention to complete. The goal is not an exhaustive process inventory; it is a ranked list of the twenty to thirty processes that consume the most time or introduce the most error when done manually.

   Group the processes by type: data ingestion, classification, routing, generation, review, and approval. This grouping becomes the foundation of your shared workflow taxonomy in step two. ISO/IEC 42001:2023 section 4.4 requires an organisation to determine the processes needed for its AI management system and their interactions before selecting or deploying AI tools. For a HoldCo, that determination must happen at the portfolio level, not venture by venture, because the legal compliance obligation sits with the parent entity.

   What this looks like in a real portfolio: In voolama's portfolio, the audit revealed that client onboarding, content classification, and reporting aggregation each appeared in some form across DAVE, The DAM Republic, Rarovera, and Airport Online. The surface-level processes looked different in each venture; the underlying data transformation pattern was the same. That shared pattern is what makes a shared tool viable. Without the audit, each venture would have procured independently and built four incompatible integrations for the same underlying need.

   Do this

   Interview one operator from each venture and ask them to list the five tasks they repeat most often.,Log each task with: venture, frequency, average time per instance, and current tooling.,Mark tasks where the output feeds another venture's input - these are your highest-value orchestration candidates.,Rank the full list by time-cost and error frequency combined.

   Example

   Across voolama's four ventures, the audit identified 'client reporting' as a shared process category appearing in Rarovera (consulting reports), The DAM Republic (vendor comparison outputs), and Airport Online (SaaS usage summaries). Recognising the shared category meant the portfolio could evaluate one reporting automation tool rather than three, and apply a single HITL review standard rather than defining one per venture.

   Best practice

   Keep the audit lightweight: a shared spreadsheet and structured interviews per venture is enough. The point is directional clarity, not a consulting deliverable. Revisit the map every six months as ventures evolve. If a venture lead cannot describe their top five recurring processes in thirty minutes, that is itself a signal that process maturity is too low for AI deployment in that venture.
2. 2

   Define a Shared Workflow Taxonomy

   A shared workflow taxonomy is a short, agreed vocabulary for the types of work the portfolio does. It typically contains six to ten categories, such as 'data ingestion', 'content generation', 'decision routing', 'client communication', 'reporting', and 'compliance review'. Every AI tool the portfolio evaluates must map to at least one category. Every new process identified in step one must be assigned a category before tooling is selected.

   The taxonomy does two things. First, it prevents duplicate procurement: if two ventures both need 'document classification', the portfolio evaluates one tool for that category rather than two. Second, it creates a common language for governance conversations, so that a compliance question about AI-generated content can be answered at the portfolio level rather than re-litigated venture by venture.

   The NIST AI RMF 'Govern' function (January 2023) calls for organisations to establish policies and procedures that apply across AI use cases rather than treating each deployment as a standalone governance problem. A shared taxonomy is the practical instrument that makes portfolio-level governance possible without requiring central approval for every configuration decision.

   Do this

   Draft the taxonomy in a shared document and circulate it to one lead from each venture for a single round of feedback.,Cap the taxonomy at ten categories for the first version.,Assign each process from the step-one audit to a taxonomy category.,Publish the taxonomy as a one-page reference document accessible to all venture leads.

   Example

   voolama's portfolio taxonomy includes categories such as 'workflow automation', 'asset classification', 'client reporting', and 'content publishing'. When DAVE and The DAM Republic both identified a need for AI-assisted metadata tagging, the taxonomy made clear that both needs mapped to the 'asset classification' category. That mapping meant a single vendor evaluation covered both ventures rather than two separate procurement exercises running in parallel.

   Best practice

   Resist the urge to create sub-categories in the first version. A flat, ten-item taxonomy that everyone understands is more useful than a hierarchical one that requires a guide to navigate. Complexity can be added in version two, once the portfolio has operated with the taxonomy for at least one quarter and the gaps are visible from real use rather than anticipated in advance.
3. 3

   Set Portfolio-Level Data and Governance Standards

   AI tools are only as reliable as the data they operate on and the governance that surrounds their outputs. At the portfolio level, two standards need to be set before any venture goes into production with an AI tool: a data classification policy and a human-in-the-loop (HITL) policy.

   The data classification policy defines which data categories can be processed by external AI services, which must stay on-premises or in a private cloud, and which require explicit consent before processing. This maps directly to EU AI Act Article 10, which sets data governance requirements for AI systems, and to ISO/IEC 42001:2023 section 6.1, which requires organisations to plan for AI-related risks and opportunities before deployment.

   The HITL policy defines, for each workflow taxonomy category, the minimum level of human review required before an AI output is acted upon. EU AI Act Article 14(4) requires meaningful human oversight for high-risk AI systems; even for lower-risk workflows, a documented HITL checkpoint is the single most effective control against compounding errors in automated pipelines. The NIST AI RMF 'Govern' function (January 2023) requires that roles and responsibilities for human oversight be defined before deployment, not after an incident.

   In voolama's portfolio, the data classification policy distinguishes between Airport Online's public-facing SaaS data, which can be processed by approved external AI APIs, and Rarovera's client engagement data, which is classified as restricted and cannot leave the client's agreed infrastructure boundary without explicit written consent. That distinction, made once at the policy level, prevents the need to re-litigate the question for each new AI tool either venture evaluates.

   Do this

   Classify your data into three tiers: public, internal, and restricted. Define which AI tool categories can touch each tier.,For each workflow taxonomy category, define the HITL checkpoint: who reviews, what they are checking for, and what constitutes approval.,Reference EU AI Act Article 10 and Article 14(4), ISO/IEC 42001:2023 section 6.1, and NIST AI RMF 'Govern' function as the baseline for your governance language.,Review both policies with legal counsel before any venture goes into production.

   Example

   For voolama's portfolio, the HITL policy is written as a decision table with four columns: workflow category, AI risk classification (using the EU AI Act's four-tier risk model), reviewer role, and approval mechanism. The 'client reporting' category is classified as limited risk under the EU AI Act, so the HITL checkpoint requires a named reviewer to confirm factual accuracy before the report is sent, rather than a full human redraft. The table format makes it immediately clear when a new workflow category is added but the reviewer role has not yet been assigned.

   Best practice

   Write the HITL policy as a decision table, not a narrative. A table with columns for workflow category, AI risk level, reviewer role, and approval mechanism is faster to apply under pressure than a paragraph of prose. The table format also makes gaps visible: an empty cell in the 'reviewer role' column is an immediate signal that a control is missing.
4. 4

   Identify and Run a Reference Implementation

   A reference implementation is a single, contained AI deployment in the venture best positioned to succeed: the one with the cleanest data, the most documented processes, and an operator willing to report honestly on what works and what does not. Its purpose is to produce a reusable pattern, not just a working tool.

   Choose the reference venture by scoring each venture on three dimensions: data quality (is the data clean, labelled, and accessible?), process maturity (are the relevant processes documented and consistently followed?), and operator readiness (is there a named person who will own the implementation and report on it?). The venture with the highest combined score is the reference candidate.

   Run the reference implementation for a fixed period, typically eight to twelve weeks, with a defined success metric agreed in advance. ISO/IEC 42001:2023 section 8.4 requires organisations to evaluate AI systems in a controlled setting before broader deployment. A reference implementation is the practical form that controlled evaluation takes in a multi-venture portfolio.

   At the end of the period, extract the reusable artefacts: the integration pattern, the HITL checkpoint design, the vendor configuration, and the lessons learned. These artefacts become the starting point for the next venture's implementation, compressing its setup time and reducing the risk of repeating the same configuration mistakes.

   Commercial interest note: voolama operates DAVE, an AI workflow orchestration product suited to the orchestration layer in a reference implementation. The reference implementation step is valid regardless of which orchestration platform a portfolio uses; the principle is not tool-specific.

   Do this

   Score each venture on data quality, process maturity, and operator readiness using a simple 1-3 scale.,Select the highest-scoring venture as the reference implementation site.,Define one primary success metric before the implementation starts.,Schedule a lessons-learned session at the end of the reference period and document the reusable artefacts.

   Example

   In voolama's portfolio, Airport Online was selected as the reference implementation site for an AI-assisted content update workflow because it had the most structured data (airport information in a consistent schema), the most documented update process, and a named operator accountable for the outcome. The integration pattern and HITL checkpoint design developed during that implementation were then adapted for The DAM Republic's content publishing workflow, reducing the second implementation's setup time significantly compared to starting from scratch.

   Best practice

   Resist pressure to run multiple reference implementations simultaneously. The value of the reference model is the learning it produces; parallel implementations produce parallel learning that cannot be consolidated until both are complete. One implementation done well is worth more than three done in parallel.
5. 5

   Build the HoldCo Orchestration Layer

   Once the reference implementation has produced a reusable pattern, the HoldCo orchestration layer formalises that pattern into a shared capability. The orchestration layer is not a centralised IT department; it is a small set of shared integrations, standards, and monitoring tools that any venture can plug into without rebuilding the underlying infrastructure.

   In practice, the orchestration layer typically includes: a shared workflow orchestration platform configured once at the HoldCo level and extended per venture; a centralised logging and monitoring setup so that AI outputs across the portfolio can be audited in one place; and a vendor registry that records which tools are approved, which data tiers they can access, and which HITL checkpoints apply to their outputs.

   ISO/IEC 42001:2023 section 5.3 requires organisations to assign responsibility and authority for AI management system roles. For a HoldCo, that assignment belongs at the portfolio level, not delegated entirely to individual ventures, because the audit and compliance obligations apply to the legal entity. The orchestration layer owner is the practical expression of that assignment.

   In voolama's portfolio, the orchestration layer is anchored by DAVE, which handles workflow triggers and routing across ventures, with venture-specific configurations layered on top of a shared base. When Airport Online joined the shared layer, it inherited the base configuration and adapted it for its own use case rather than procuring and configuring a new platform independently.

   Do this

   Select a workflow orchestration platform that can be configured at the HoldCo level and extended per venture.,Build the centralised logging setup before any venture beyond the reference implementation goes into production.,Create the vendor registry as a shared document and assign one owner responsible for keeping it current.,Define the process for a venture to request a new tool: who evaluates it, against what criteria, and within what timeframe.

   Example

   voolama's vendor registry is a shared document listing each approved AI tool, the taxonomy category it covers, the data tier it can access, and the HITL checkpoint that applies to its outputs. When a venture lead evaluates a new tool, the first check is whether it maps to an existing registry entry. If it does, the evaluation criteria are already defined. If it does not, the venture lead submits a new category proposal for portfolio-level review before procurement begins.

   Best practice

   Keep the orchestration layer as thin as possible. Every component added to the shared layer is a dependency for every venture. Add components only when the cost of each venture managing that component independently is demonstrably higher than the cost of centralising it. Document the architecture in a single page that any venture lead can read without a technical background.
6. 6

   Measure Outcomes and Iterate

   An AI operating model that is not measured is not managed. The measurement framework should be set up before the first venture beyond the reference implementation goes live, so that baseline data exists for genuine comparison.

   Measure at two levels. At the venture level, track the outcome metrics defined in step one: cycle time for the targeted processes, error rate on AI outputs before HITL review, and decision latency. At the portfolio level, track the efficiency of the shared orchestration layer: how many ventures are using it, how many tools are on the approved vendor list versus in use, and how many HITL checkpoints are being completed on schedule.

   Review the portfolio-level metrics quarterly. Review venture-level metrics monthly. When a metric moves in the wrong direction, the first question is always whether the process design or the data quality has degraded, not whether the AI tool has failed. The NIST AI RMF 'Improve' function (January 2023) formalises this as a continuous process: AI risk management is a recurring operational discipline, not a one-time design exercise.

   In voolama's portfolio, the quarterly operating model review is the mechanism for surfacing taxonomy gaps, HITL checkpoint failures, and vendor registry drift. The review is attended by one lead from each venture and the HoldCo orchestration layer owner. Its output is a short list of changes to the operating model, not a list of tool replacements.

   Do this

   Set baselines for cycle time, error rate, and decision latency before any AI tool goes into production.,Build a simple portfolio dashboard that aggregates venture-level metrics into a single view for the HoldCo.,Schedule quarterly operating model reviews with all venture leads.,Create a lightweight process for a venture to flag a metric moving in the wrong direction between scheduled reviews.

   Example

   In voolama's portfolio, a quarterly review identified that the HITL checkpoint for Rarovera's AI-assisted proposal drafting was being completed inconsistently: some proposals were reviewed by a named approver, others were sent directly to clients without review. The root cause was not tool failure but an ambiguous approval mechanism in the HITL policy table. The fix was a single-line clarification in the policy table specifying that the approver must log their review in the shared document before the proposal is sent. The measurement framework made the gap visible; the operating model review produced the fix.

   Best practice

   Do not add metrics for their own sake. Three metrics measured consistently are more useful than ten metrics measured inconsistently. Start with cycle time, error rate, and decision latency, and add only when a specific operational question cannot be answered by those three.

Why the Operating Model Comes Before the Tools

What This Guide Does Not Cover

Commercial Interest Disclosure

FAQ

What does 'AI-ready' actually mean for a multi-venture portfolio?

AI-ready means every venture in the portfolio can adopt, integrate, and govern AI tools without starting from scratch each time. At the portfolio level it means shared data standards, a common workflow taxonomy, and a governance layer that satisfies frameworks like ISO/IEC 42001:2023 and the EU AI Act. At the venture level it means clean data pipelines, documented processes, and staff who understand where human judgment is required.

Should AI governance sit at the HoldCo level or inside each venture?

Governance policy and vendor evaluation criteria belong at the HoldCo level so they are consistent across the portfolio and auditable in one place. Execution, meaning which specific tools a venture uses and how they are configured, belongs inside each venture. This split prevents the HoldCo from becoming a bottleneck while ensuring no venture creates a compliance gap that exposes the whole portfolio.

How do you prevent AI tool sprawl across a portfolio of ventures?

Establish a short approved-vendor list and a lightweight evaluation rubric at the HoldCo level before individual ventures start procuring. Require each new AI tool to map to an existing workflow category in the shared taxonomy. Any tool that does not map to an existing category triggers a portfolio-level review rather than a unilateral venture decision. This keeps the stack coherent without requiring central approval for every configuration change.

What is the right sequence for rolling out AI across multiple ventures?

Start with the venture that has the cleanest data and the most documented processes, use it as a reference implementation, and extract the reusable patterns before rolling to the next venture. Attempting a simultaneous portfolio-wide rollout without a reference implementation almost always produces inconsistent results and makes it impossible to diagnose what went wrong and where.

How do you measure whether the AI operating model is working?

Track outcome metrics rather than adoption metrics. Useful signals include cycle time for recurring decisions, error rate on automated outputs, and decision latency, the time between a trigger event and a human-approved action. Tool count and feature usage are lagging indicators of adoption, not leading indicators of value. Set a baseline before any AI tooling is introduced so you have a genuine comparison point.