Artificial intelligence is no longer advancing through isolated model improvements alone. The more disruptive shift is now happening at the feature layer. Enterprise users are not simply receiving better chatbots, faster summarisation tools or more capable drafting assistants. They are receiving entirely new operating capabilities: autonomous agents, embedded copilots, workflow executors, multimodal assistants, AI-generated analytics, tool-using systems, memory-enabled assistants and AI features that can act across documents, messages, applications and business processes.
That matters because many enterprise governance processes were designed around a narrower category of AI use. They assumed that AI would mostly generate content, answer questions, classify data, summarise documents or support a human user who remained clearly in control. Those assumptions are starting to fail. A product that yesterday helped an employee write a report may tomorrow be able to search internal systems, trigger workflows, update customer records, draft outbound communications, analyse sensitive files and recommend or execute decisions. The name of the product may not change. The licence may not change. The vendor may describe the update as a feature enhancement. But the risk profile can change completely.
This is why AI governance must now move beyond policy documents and acceptable use statements. Enterprises need operational controls capable of recognising when a new feature set has changed the boundary of what requires regulation, governance and control.
Feature releases are redefining the control perimeter
Traditional IT governance often works reasonably well when software capability is stable. A system is procured, assessed, configured, approved, deployed and monitored. Material changes may trigger review, but the basic operating model assumes that the system’s role is understood.
AI products break that model because their capabilities can expand quickly and sometimes quietly. A vendor can add agentic functionality, persistent memory, plug-in access, document ingestion, code execution, browser access, API actions, automated meeting participation or cross-application workflow execution. Each of those changes can move the product into a different governance category.
The most important issue is not whether the feature is impressive. It is whether the feature changes what the system is capable of doing inside the organisation.
A basic AI drafting assistant may require controls around confidentiality, accuracy, copyright, records management and human review. An autonomous agent that can access operational systems introduces a different class of risk: authorisation risk, process integrity risk, accountability risk, transaction risk, data minimisation risk, escalation failure, auditability failure and incident reversibility. A multimodal tool that can interpret screenshots, contracts, identity documents or employee records may introduce new privacy, discrimination, security and evidential risks. A model with memory may create retention, purpose limitation and data subject rights issues. A system that can recommend decisions affecting employees or customers may move into fairness, explainability, human oversight and automated decision-making territory.
The governance question is therefore not “Are we using AI?” The better question is: “What can this AI now do, with what data, through which integrations, under whose authority, with what oversight, and with what evidence trail?”
Agentic AI creates a new class of enterprise risk
Agentic AI is particularly significant because it changes AI from a support tool into an operational actor. Even where a human remains involved, the AI may be planning tasks, selecting tools, sequencing actions, interpreting business rules, escalating exceptions or initiating outputs that affect real-world processes.
That creates a new risk category: delegated operational execution.
Most organisations already understand the risks of a human making a poor decision. They have policies, controls, approval routes, training, system permissions, segregation of duties and audit logs. But when an AI agent acts within or across business systems, those controls may not map cleanly.
Who authorised the action? Was the agent operating within an approved use case? Was the underlying model updated after approval? Was the prompt or tool configuration changed? Did the user understand the action the agent was about to perform? Was the output checked before it affected a customer, employee, supplier or regulated process? Can the organisation reconstruct the chain of reasoning, data access, tool calls and final action? Can it reverse the action if the agent performed incorrectly?
These are not theoretical concerns. They are practical governance problems. Without clear controls, agentic AI can create failures that are hard to detect, hard to explain and hard to unwind.
Existing onboarding processes are becoming insufficient
Most enterprises already have onboarding processes for new technology. Procurement, information security, data protection, legal, architecture, vendor management and operational teams may all be involved. For conventional software, that process can work well. For fast-moving AI products, it is often too static.
The problem is that AI features can change after the initial review. A product may pass procurement as a low-risk productivity tool, then later gain access to sensitive data, automated workflow actions or embedded decision-support functions. If governance only happens at initial onboarding, the organisation may be relying on an outdated assessment.
This is especially important for vendor due diligence and Data Protection Impact Assessments.
Vendor due diligence can no longer be a generic security questionnaire with a few AI questions attached. It needs to examine the AI-specific operating model: model providers, data retention, training use, subprocessors, prompt and response logging, admin controls, audit logs, model update management, human oversight, explainability, fallback processes, incident handling, data residency, role-based access, integration scope, agent permissions and contractual responsibility for harmful or non-compliant outputs.
DPIAs also need to evolve. A DPIA for a basic AI assistant is not the same as a DPIA for an AI agent that processes personal data, profiles individuals, recommends decisions, monitors behaviour or interacts with customer and employee records. The ICO’s AI and data protection guidance makes clear that AI systems processing personal data require attention to data protection compliance, organisational measures and risks to individuals, and that other legal frameworks may also be relevant alongside data protection law.
A DPIA must therefore assess the actual capability being deployed, not just the product name.
The boundary problem: when does a feature become a regulated capability?
One of the hardest challenges for CIOs, CISOs, CTOs, DPOs and procurement leaders is boundary classification. The same AI product may sit in different risk categories depending on how it is configured and used.
For example:
A chatbot answering internal policy questions may be low to moderate risk.
The same chatbot connected to HR files, absence records and performance data may become a high-risk privacy and employment governance issue.
An AI assistant summarising customer emails may be useful.
The same assistant drafting and sending customer responses may introduce conduct, brand, legal and evidential risk.
A code assistant helping developers write functions may be manageable.
The same assistant generating production infrastructure changes may create security, resilience and change-control risk.
An AI meeting assistant transcribing calls may raise privacy and confidentiality questions.
The same assistant analysing sentiment, performance or behaviour may introduce employee monitoring and fairness issues.
This is why feature classification must become a formal governance control. Enterprises need a structured way to identify whether an AI feature is merely assistive, advisory, decision-supporting, decision-making or action-executing. They also need to classify the data being used, the population affected, the business process involved and the severity of harm if the system behaves incorrectly.
A new approach to AI vendor due diligence
AI vendor due diligence should become dynamic, evidence-led and capability-specific. It should not be treated as a one-off procurement hurdle.
A stronger due diligence model should include:
- Capability mapping
What AI functions does the product provide today, and what roadmap features could materially change the risk profile? - Data flow analysis
What data is processed, where does it go, who can access it, how long is it retained, and can it be used to train or improve models? - Model and provider transparency
Which models are used, which providers are involved, and can the vendor change model architecture or subprocessors without notice? - Agent and tool permissions
Can the AI call tools, trigger actions, access systems, update records or operate autonomously? - Human oversight design
Where must a person review, approve, override or reject outputs before they affect real processes? - Auditability and evidence
Can the organisation reconstruct prompts, data access, model outputs, user approvals, tool calls and final actions? - Change monitoring
How will the organisation know when vendor updates introduce new AI features or materially alter existing ones? - Contractual allocation of responsibility
Who is responsible for errors, security failures, data misuse, discriminatory outputs or non-compliant automated actions?
Strategic AI Guidance has built practical tooling to support this kind of structured review. The AI Vendor Due Diligence Assistant is designed to help organisations review AI vendors before procurement, deployment or renewal, using structured question packs, evidence sufficiency checks and risk scoring.
DPIAs must become capability-aware
DPIAs need the same shift. Many organisations still treat DPIAs as form completion exercises. That is inadequate for AI. The DPIA must understand what the AI system actually does, what personal data it processes, whether special category data is involved, whether individuals may be profiled or monitored, whether decisions could affect rights or opportunities, and whether the system introduces fairness, accuracy, transparency or explainability concerns.
For AI, the DPIA also needs to consider model behaviour, prompt design, vendor retention, training use, cross-border transfers, human oversight, automated decision-making, output validation, logging, security, incident response and operational monitoring.
The difficulty is that this is not static. A DPIA performed before agentic features are enabled may become stale if the product later gains new autonomy, memory, integrations or action permissions. DPIA governance must therefore include triggers for reassessment. These triggers should include new data categories, new user groups, new integrations, new model providers, new automated actions, new monitoring functions, new decision-support use cases and material vendor feature releases.
Strategic AI Guidance also provides AI DPIA support as part of its practical software and governance toolkit, alongside vendor due diligence, AI assessment, policy review, approval workflows and evidence-led reporting.
Governance must become operational
The enterprise answer is not to block AI innovation. Blocking demand rarely works. If official routes are too slow, shadow AI grows. Employees and departments will find their own tools, run their own pilots and use embedded features already sitting inside licensed platforms. The result is not less risk. It is unmanaged risk.
The better answer is controlled adoption.
Controlled adoption means giving the business a clear route to use AI safely. It means fast triage, proportionate review, reusable control patterns, approved vendor registers, DPIA templates, evidence workflows, escalation routes and board-level reporting. It also means treating AI governance as a live operating model rather than a document set.
A mature enterprise approach should include:
An AI use-case register.
A vendor AI capability register.
A risk classification model for AI features.
AI-specific procurement gates.
AI-specific DPIA triggers.
Human oversight and approval rules.
Technical controls for data access and action permissions.
Operational monitoring after deployment.
Board reporting across vendors, use cases, incidents and residual risk.
Clear ownership across IT, security, legal, data protection, procurement and business teams.
This is the shift many enterprises now need to make. AI governance can no longer sit outside delivery as an advisory function that reviews documents after decisions have effectively been made. It must be embedded into onboarding, procurement, architecture, data protection, vendor management, security, change control and business process design.
The board-level issue
For boards and executive teams, the core issue is not whether the organisation has an AI policy. The issue is whether the organisation can identify, classify, approve, monitor and evidence AI use as capabilities evolve.
If a major vendor enables new agentic features next quarter, will the organisation know which business units are exposed? Will it know whether personal data is involved? Will it know whether the feature affects regulated processes? Will it know whether a fresh DPIA is required? Will procurement know whether vendor due diligence needs to be refreshed? Will security know whether new integrations or permissions have been introduced? Will operational teams know how to pause, reverse or investigate AI-driven actions?
If the answer is no, the governance model is behind the technology.
Conclusion
AI features are moving faster than enterprise controls because the nature of AI products is changing. New feature sets are not simply improving productivity. They are redefining what software can do, what risks it creates, and where regulation, governance and control must apply.
Autonomous agents, embedded copilots, memory-enabled assistants and AI workflow executors require a different governance model from traditional SaaS tools or first-generation generative AI. Vendor due diligence must become AI-specific, dynamic and evidence-led. DPIAs must become capability-aware and revisited when features materially change. Boards need reporting that shows not only which tools are approved, but what those tools can do, what data they touch, what decisions or actions they influence, and what controls are in place.
The organisations that get this right will not be the ones that move slowly. They will be the ones that make safe adoption faster than shadow adoption.