PETALS™ Framework for AI Governance

A practical structure for cross-functional teams to avoid pitfalls in artificial intelligence initiatives.

The Problem

PETALS Framework — Purpose at the centre with Effort, Tools, Assembly, Leverage, and Secure radiating outward like petals of a hibiscus.

Artificial intelligence has captured boardroom attention. Capital is flowing, vendors are crowded, and headlines promise economic transformation. Yet the abandonment rate of AI projects remains stubbornly high. Industry analysts have warned that at least thirty percent of generative AI projects will be discontinued. In our advisory work, we have seen figures considerably higher in some sectors.

The reasons are recognisable. Poor data quality. Inadequate risk controls. Escalating costs. Unclear business value. Most of these failures trace back not to the limits of the technology itself but to how organisations approach AI initiatives.

In engagements with management teams and technical specialists at established firms and startups alike, a familiar pattern emerges. Business leaders speak with authority about their domain. They make assumptions about technology and data that do not hold up under scrutiny. Technical teams jump straight to the tool stack. They rush to produce a working prototype to satisfy the business sponsor. Data sets get cherry-picked. Model parameters get tweaked, often justified as for the demo only. Polite conversations become arguments. Arguments end in stalemate.

These are the telltale signs of impending AI failure. PETALS™ exists to prevent them.

What PETALS™ Is

PETALS™ is a framework for governing AI initiatives. It provides a simple structure for cross-functional teams to follow with measured flexibility. The framework is centred on Purpose, with five operational dimensions arranged around it like the petals of a hibiscus.

Letter	Pillar	Functional Ownership
P	Purpose	Sponsor
E	Effort	Technology and data architects
T	Tools	Technology team
A	Assembly	Technology and operations
L	Leverage	Technology and data team
S	Secure	Cyber and risk team

The framework is designed to be applied fluidly, not as a linear checklist. It evolves with each engagement. It is a living, breathing instrument intended to absorb learning from the practitioners who use it.

PETALS™ is a registered trademark with the Intellectual Property Office of Singapore.

The Six Pillars

P — Purpose

Always begin with the end in mind. Purpose comes from the sponsor. It states clearly what the initiative is intended to accomplish. To predict weather. To forecast stock prices. To monitor carbon emissions. To detect the next cyberattack rather than respond to it.

Purpose is more than the end goal. It must also describe the journey and the timeframe the sponsor is willing to invest in. AI initiatives are experimental and iterative by nature. They rarely yield the expected outcome on the first attempt. A purpose that pretends otherwise will collapse at the first obstacle.

A sponsor who cannot articulate Purpose in plain language should not yet be funding an AI initiative.

E — Effort

An AI initiative often begins on the left side of the X-axis. Size up the effort required just to reach the start point — the origin (0,0). This is where most projects underestimate.

Reaching the start point requires a substantial cross-functional team effort. Data must be collected. Scrubbed. Normalised. Maintained for relevance, context, and usefulness across the lifecycle of whatever models the initiative will use. This applies to both training data and test data, structured and unstructured.

Effort estimation also extends to the people involved. Data engineers. Architects. Domain experts. Operations staff who will inherit the workflow. Underestimating any one of these is a leading cause of project drift.

T — Tools

Selecting the right tools is no mean feat. Generative AI. Conventional AI. Machine learning. Deep learning. The choice between them, and more importantly the sequence and combination in which they are used, requires clear design thinking and a roadmap that breaks aspirations into bite-sized chunks.

Tool selection requires niche expertise. Architects, data analysts, full-stack developers. Their role is not only to pick the model but to assess whether a given model is the specific hammer for the specific nail. Models are often misapplied because they are familiar to the team, not because they fit the problem.

The sequence of models in the overall workflow must be connected through standard tools for slicing, merging, and aggregating data sets. Increasingly, this also includes tools for masking, tokenising, and encrypting sensitive data as it moves through the pipeline.

A — Assembly

A final working technical solution rarely resembles the first version of the architecture document. The first version serves as a planning guide. The actual solution evolves through assembly and experimentation.

Assembly is the discipline of building toward a working solution while remaining agnostic to hardware, vector stores, and other infrastructure choices that may change. It applies the principles of confidential computing, identity and access management, and data protection through masking, tokenisation, or encryption. Key management becomes a first-class concern, not an afterthought.

One decision deserves particular attention at the Assembly stage: closed-source versus open-source models. The right answer depends on the business use case. An enterprise may legitimately use both, for different purposes. The investment required for transparency and explainability through surveillance and monitoring capabilities must be factored in and balanced against the investment required to build a safe and trusted environment.

L — Leverage

Knowing how to leverage the parameters of a model to maximise its efficacy in a specific business context requires mastery of both the data and the model. This is not a one-time setup. It is a continuous discipline.

Levers need to be fine-tuned regularly. The conditions under which the model operates will shift. Data distributions drift. Business contexts evolve. Adversarial conditions emerge. Without continuous attention to leverage, model performance degrades silently until a downstream failure makes it visible.

The ideal person for this work is a genuine machine learning expert and a data specialist, ideally combined in one. Operationally, a cross-functional team validates the end-to-end workflow at every stage of design. Business process analysts. Data analysts. System architects. Tool and test champions. Operations staff with practiced run books who have experienced disruptions and crisis conditions.

S — Secure

Building a safe and trusted AI environment requires more than classical cybersecurity. It requires planning for the adoption of industry standards and frameworks in a progressive and sustainable manner.

The roadmap should be informed by established guidance. The NIST AI Risk Management Framework. MITRE ATLAS for adversarial threat modelling. The OWASP GenAI Security Project. The OWASP Top 10 for Machine Learning. These are not abstract reference works. They are operational tools that translate into specific controls, processes, and capabilities.

Beyond the classical CIA triad of confidentiality, integrity, and availability, AI deployment demands explicit treatment of privacy, anonymity, trust, transparency, traceability, responsibility, explainability, and ethics. These are not optional refinements. For most regulated and high-trust environments, they are non-negotiable.

Enterprises pursuing assurance should consider certification pathways. ISO 42001 for AI management systems. ISO 23053 for AI using machine learning. ISO 23894 for AI risk management. These work alongside the established assurance frameworks such as ISO 27001 and SOC 2 Type 2 that most enterprises already maintain.

How to Apply PETALS™

PETALS™ is most useful at three points in an AI initiative.

At the planning stage, it provides a structured conversation between the business sponsor and the technical team. Each pillar prompts the question: who owns this, and what is the evidence that we are ready? Projects that cannot answer for all six pillars are not yet ready to launch.

At the design review stage, it serves as a checkpoint against pitfalls. A working architecture should be testable against each of the six pillars. Where one is weak, the project documents the weakness and assigns accountability.

At the post-implementation review, it forms the basis for honest assessment. Which pillars held up? Which broke down? What does that tell the organisation about how it approaches AI initiatives more broadly?

Grey Orbits applies PETALS™ in board engagements, executive workshops, and technology due diligence. The framework adapts to the audience. For boards, it surfaces the governance questions that warrant attention. For executive teams, it structures the cross-functional conversation that determines whether an AI initiative is investable. For investors and acquirers, it provides a lens for assessing the AI capability and AI risk posture of target companies.

A Living Framework

PETALS™ continues to evolve. As agentic AI matures, as regulatory expectations sharpen, as enterprise adoption deepens, the framework absorbs new dimensions of practice. Practitioners using it in their own engagements are encouraged to share their findings. The framework is offered in a spirit of contribution to the broader discipline.

Sources and Further Reading

Standards and Frameworks

Assurance Frameworks

Related Grey Orbits Frameworks

This methodology is offered under a Creative Commons Attribution 4.0 International Licence. Practitioners and educators are welcome to reference and adapt the methodology, with attribution to Grey Orbits and a link back to greyorbits.com.

PETALS™ is a registered trademark with the Intellectual Property Office of Singapore. The trademark protects the PETALS™ name and mark. Adaptations of the methodology under the CC-BY licence should not be branded as PETALS™ without permission.

For advisory engagements applying this framework to your AI governance or operating model, contact support@greyorbits.com.

CC-BY Viren Mantri, 2024.

Disclaimer: All views expressed here are entirely mine.