Shared standards for advanced AI: what changes for governance, audits and enterprise adoption

OpenAI supports the creation of shared standards to evaluate and govern advanced AI systems. For companies and public bodies, the operational priority is to prepare verifiable evidence, controls and adoption criteria.

From AI promises to documented evidence

OpenAI has published a post on shared standards for advanced AI, linking it to the launch of the Appia Foundation, hosted by the Linux Foundation. According to OpenAI, Appia will work on open and modular specifications to translate international standards and existing frameworks into practical evaluation criteria across the AI value chain: models, infrastructure, applications and third parties performing assessments.

For organisations introducing generative AI, agents or LLM-based automation, the operational message matters more than the single initiative: it will no longer be enough to state that a system “uses AI safely”. Comparable evidence will be needed: what was tested, with which tools, with which access levels, which risks were considered, which mitigations are active and who is accountable.

This is relevant even for organisations that do not develop foundation models. Most companies will consume AI through APIs, cloud platforms, SaaS products or components embedded in workflows. For this reason, interoperable standards can become a trust layer between vendors, integrators, auditors, customers and regulators. Governance does not concern only the model: it concerns the whole system that receives inputs, accesses data, uses tools, produces outputs and may influence operational decisions.

What changes for companies, public bodies and technical teams

The first change concerns procurement. Assessing an AI provider can no longer be limited to performance, cost and features. Organisations should request documentation on safety evaluations, incident management, access controls, data protection, usage limitations, traceability and model updates. If an AI service is integrated into critical processes, this information must become part of contractual and technical requirements.

The second change concerns architecture. Unlike an isolated chatbot, AI agents can call tools, read databases, open tickets, send messages or activate procedures. In these cases, evaluation must include not only response quality, but also permissions, escalation paths, fallback mechanisms, environment separation, human intervention thresholds and preventive blocks for high-impact actions.

The third change is organisational. A clear accountability chain is required: who approves the use case, who validates the data, who defines the policies, who monitors errors, who decides when to suspend or modify the system. Without this structure, even the best framework remains a static document.

For many organisations, the starting point is not a large compliance programme, but a reasoned inventory of AI use cases: purpose, data processed, users, integrations, potential impacts and minimum controls. From there, it becomes possible to distinguish between low-risk experiments and applications that require more rigorous testing, audits and governance.

Evaluation, security and interoperability: three practical criteria

The OpenAI source stresses the need for credible and technically rigorous evaluation practices. In business terms, this means adopting three criteria.

The first is repeatability. An AI test should not be an informal experiment performed once. It must be described so that it can be rerun after model updates, data changes or workflow modifications. This applies to accuracy, robustness, security, bias, tool misuse and edge-case handling.

The second is proportionality. Not every use case requires the same level of control. An internal assistant for drafting text has a different risk profile from an agent interacting with ERP systems, sensitive data or regulated processes. Governance must be risk-based: the more a system can produce concrete effects, the more it needs controls, approvals and monitoring.

The third is evidence interoperability. If an application combines an external model, cloud infrastructure, company data and custom application logic, each part contributes a portion of the risk. Shared standards can help make this evidence readable across different organisations. But the company still has to design where to collect it, how to retain it and how to use it for operational decisions.

This is where cross-functional expertise becomes essential: AI, security, cloud, software engineering and governance. An enterprise AI project is not just prompt design. It is integration with existing systems, access control, observability, data management, internal policies and operational continuity.

How to prepare without waiting for final standards

Standards will evolve, and initiatives such as the Appia Foundation will have to prove their adoption, neutrality and practical value over time. However, organisations can already prepare through concrete choices.

First: define a short but applicable AI policy, connected to real processes. It should state which uses are allowed, which require approval, which data cannot be entered into external tools and when human supervision is mandatory.

Second: design technical controls from the start. AI agents and automation require roles, least-privilege permissions, separate environments, action limits, essential logging and stop procedures. Adding them later is more expensive and often less effective.

Third: introduce an evaluation sheet for each use case. It does not need to be bureaucratic: objective, data, providers, integrations, risks, tests performed, owner, metrics and review plan. This document becomes useful for audits, maintenance and scaling decisions.

Fourth: avoid decision lock-in. The use of open standards and documented criteria helps compare vendors and architectures, reducing dependence on commercial claims that are difficult to verify.

For Dedaloop, the direction is clear: useful enterprise AI will increasingly be AI designed as a governed system, not as an isolated experiment. Shared standards do not remove internal responsibility, but they provide a common language to make it more verifiable.

Approfondimenti Dedaloop

Fonti