The Enterprise AI Adoption Framework: Four Parts for Governed Innovation

A marketing team does not need to choose between stopping AI experiments and letting every experiment reach client work. It needs a route from a useful idea to a capability the organisation can support.

That route has four parts: an approved catalogue for work, a sandbox for exploration, a promotion path between them, and shared education that helps people use all three. Practitioners bring knowledge of the work. Security, engineering, data owners, and leaders set boundaries and help make useful experiments dependable.

The problem is a missing route

A team discovers that an AI workflow could shorten a recurring task. Practitioners want to test it; security and governance teams need to understand its data access and effects. Both concerns are legitimate. If every capability has to be built centrally, domain knowledge and opportunities can get stuck in a queue. If anyone can install tools or connect them to client systems without review, the organisation can lose track of data, permissions, costs, and support responsibility.

That second risk is not hypothetical. Cisco researchers demonstrated data exfiltration through a malicious third-party skill in an OpenClaw setup, while Palo Alto Networks describes how private-data access, untrusted content, and external communication can combine into an agent security risk. These examples do not prove that every skill is dangerous. They show why the surrounding runtime and permissions matter as much as the skill description. Cisco’s research · Palo Alto Networks’ analysis

The practical choice is between governed adoption and ungoverned adoption, not adoption and no adoption. Governance works best when it gives people a clear way to contribute and gives the organisation a clear way to assess, support, restrict, or retire what they build.

Four parts of a governed adoption framework

1. The authoritative catalogue

The catalogue is the place practitioners find capabilities approved for defined work. It may feel like an internal app store, but a list of links is not enough. Each entry needs a purpose, version, named owner, supported users, data classification, permitted tools and systems, known limits, and a route for reporting problems.

Examples might include a campaign KPI explorer, brand-safety checker, bid-strategy simulator, or creative-compliance reviewer. The catalogue should say whether a capability is for experimentation, internal work, or client-facing use. “Approved” must refer to a particular version and operating context. It does not mean that every user, dataset, or action is automatically permitted.

If the organisation already has a trusted portal that reflects teams and roles, it can help people find relevant capabilities. Personalisation improves discovery; identity and authorization controls still decide what a person or agent may access.

2. The sandbox

A sandbox gives practitioners a place to build, test, and break prototypes without reaching production systems or exposing client data by default. It might use containers or another isolated runtime, synthetic or approved redacted data, test APIs, limited network access, separate credentials, and cost limits.

A media strategist could prototype a budget-pacing assistant against synthetic campaign records. A creative lead could test a brand-voice review workflow against approved sample copy. A data analyst could automate a report using a non-production export. They can learn by trying the workflow, inspecting where it fails, and improving it before asking for production access.

A sandbox is not safe merely because it is called a sandbox. Its isolation, data, network permissions, secrets, logging, and reset process need to be designed and checked. A prompt or skill file can describe intended behaviour, but it cannot enforce operating-system permissions, restrict network access, or protect a credential available to the agent. Enforce those boundaries outside the model and its instructions.

Without a supported environment, experimentation may move to personal machines, side channels, or unreviewed services. A well-designed sandbox makes the work visible and gives people a practical alternative, while keeping its limits explicit.

3. The promotion path

The promotion path turns a promising experiment into a supported catalogue capability. A useful path is visible before someone starts building:

1. Propose the workflow and identify its users.
2. Review the purpose, data, permissions, and expected effects.
3. Test the implementation in the runtime where it will operate.
4. Confirm the data owner, technical owner, and service owner.
5. Publish a versioned entry with monitoring, support, and review arrangements.
6. Reassess, restrict, suspend, or retire it when its scope or risks change.

The gates should match the capability’s risk. Before promotion, the team should know what data it reads or changes; which identities and credentials it uses; how tools and network access are constrained; how outputs are tested; what gets logged; who handles incidents; and how the capability is disabled or rolled back. Human review of the skill or code is useful, but does not replace runtime controls.

A promotion record makes ownership and revocation concrete. This example is a template, not a deployed programme:

Field	Example record
Capability and status	Campaign KPI weekly report; proposed
Proposer	Media analytics team
Service owner	Marketing analytics platform
Technical owner	Platform engineering
Approved data	Synthetic or explicitly approved aggregate campaign data
Permitted operations	Read approved report tables; create an internal draft report
Prohibited operations	Change budgets or bids; send reports to clients
Runtime	Isolated, approved environment
Review evidence	Data-access review; code and dependency review; output quality and safety tests; logging and incident-response check
Release and review	Version assigned on approval; review date set by the service owner
Suspend or revoke if	Owner or data scope is no longer valid; material security or quality issue appears; capability exceeds approved permissions

The record binds the review to an owner, a version, a data scope, and an operating environment. If those change, the organisation can review the approval instead of assuming it still applies.

4. Education and shared practice

Education is the layer that makes the other three usable. It is more than a policy document or annual compliance course. It includes practical instructions, examples, and places to get timely help.

Useful materials include role-specific safe-use checklists; patterns for building and reviewing capabilities; examples of approved and rejected submissions; short sessions using realistic scenarios; and a channel where people can ask whether a tool, repository, or data source is appropriate. Highlighting successful, reviewed experiments can spread practice and reward good contribution.

A catalogue nobody knows how to use will sit idle. A sandbox people cannot find will not offer a credible alternative to personal experimentation. A promotion process nobody understands will not move good work into shared use. Education supports the whole route and should be updated when the tools, policies, or risks change.

Co-creation makes governance useful

A central engineering group cannot know every broken workflow, recurring report, or decision bottleneck across a large organisation. The people closest to those tasks can describe the work and the judgment it requires. They can propose a useful capability without becoming its only engineer or permanent operator.

The organisation should make that contribution possible while separating domain expertise from production authority. A practitioner can define the workflow, examples, and acceptance criteria. Engineering can help make it reliable and maintainable. Security and data owners can check access and exposure. A service owner can accept responsibility for support and lifecycle decisions.

For a weekly performance review, a media planner could write the procedure: which comparisons matter, how to handle attribution delay, when a movement warrants investigation, and what an acceptable finding looks like. They can supply worked examples and cases where the right response is “insufficient evidence,” without learning Python or managing infrastructure. Engineering turns that contribution into a versioned skill and connects it to approved data in the sandbox. The planner helps evaluate the findings; security and the data owner review access; a service owner takes responsibility before catalogue promotion. The procedure carries domain knowledge. Its installation does not grant access to a client’s accounts or permission to change a campaign.

This is co-creation with accountable boundaries, not unrestricted self-service. The builder should receive credit, but the capability needs a support owner who can maintain or revoke it if the builder changes roles or leaves. The resulting expertise can then be shared rather than trapped in one person’s prototype.

Start with one workflow

Leaders can test the framework with one recurring task and a small cross-functional group:

1. Choose a workflow with a clear user, measurable output, and low initial risk.
2. Let practitioners propose and prototype it in a sandbox using approved test data.
3. Record the capability’s purpose, data, permissions, expected output, and failure cases.
4. Have the relevant data owner, security partner, and technical owner review it.
5. Promote only the bounded version that passes the agreed checks, with a named service owner and review date.
6. Observe use and problems, then improve, restrict, suspend, or retire the capability as evidence requires.

The first result may be a decision not to promote. That is still useful if it identifies a data, security, or support gap early. Measure whether the process helps practitioners find an approved route and whether promoted capabilities remain useful and maintainable. Do not treat the number of experiments or catalogue entries as proof of business value.

Platform context, dated 21 October 2026

Product features can make parts of this framework easier to implement, but no vendor feature supplies the organisation’s full governance model. These examples are a dated snapshot and should be checked before implementation:

• OpenAI: The Codex app supports reusable skills across the app, CLI, and IDE extension. This can help package repeatable workflows, but a skill is not an authorization boundary. Codex app overview
• Anthropic: Claude Tag lets teams give Claude access to selected Slack channels and connect chosen tools, data, and codebases. That can support collaboration, while workspace permissions and operating controls remain necessary. Claude Tag announcement
• Google: AI Studio documents a server-side runtime, secrets, external API connections, and Firebase integration for building applications. Those features can support prototypes; an organisation still has to define whether the environment is approved for its data and users. AI Studio full-stack documentation
• Microsoft: Microsoft Entra Agent ID documentation describes agent identity and lifecycle governance, including responsible sponsors and access reviews. Availability and licensing vary, and identity is one part of an adoption framework rather than the whole framework. Agent ID documentation

What this means for the series

In the agent builder playbook, The Anatomy of a Marketing Agent, and The Muscles of the Machine, the series examines skills, architecture, and tools. The Code Agent’s Playbook covers maintaining and protecting the systems that run them. This framework adds the organisational route that connects practitioner experiments to approved, supported capability. Portable Intelligence handles the next release detail: packaging that workflow, testing host compatibility, and maintaining its installations.

The catalogue, sandbox, promotion path, and education layer do not make adoption automatically fast or safe. They give an organisation a way to make trade-offs visible: what can be tried, what can reach production, who owns it, and when approval should change. The aim is not to adopt the most AI. It is to make useful adoption governable and make governance practical enough that people will use it.

Reference reading

• Cisco research on malicious third-party skills and agent security
• Palo Alto Networks on the agent security “lethal trifecta”
• OpenAI: Introducing the Codex app
• Anthropic: Introducing Claude Tag
• Google AI Studio full-stack development
• Microsoft Entra Agent ID documentation