In the past eighteen months, our teams have moved from debating whether to use AI to debating how fast we can deploy it. The harder question is how to let teams move quickly enough to capture the value of AI without allowing the company’s risk profile to expand faster than its ability to govern it.
CTO and CISO at Entrata.
That tension is familiar to technology and security leaders because AI creates two mandates that can appear to compete with each other. The technology side of the organization wants experimentation, access, speed, and a path to real productivity gains, while the security side needs control, accountability, data boundaries, and confidence that new workflows will not introduce avoidable exposure.
Both instincts are correct, which is why companies get into trouble when they treat AI as either a pure innovation project or a pure security problem. It is an operating model change, and the organizations that handle it well will be the ones that build just enough structure and hardened tools to let teams move with confidence rather than forcing them to choose between speed and control.
Start with the work, not the tool
Many companies begin by treating AI adoption like a standard software rollout. They approve a vendor, distribute licenses, publish a few guidelines, and assume usage will naturally become transformative. That approach can create activity, but it rarely creates durable operational change.
Real adoption starts when leaders understand how work actually gets done. A finance team, product team, marketing team, support team, and engineering team will not use AI tools in the same way because each group has different knowledge requirements, data sources, risk thresholds, and experience. Each of these will require the development of AI skills and tools.
Leaders should begin by asking what each function is trying to accomplish, what knowledge it needs to make better decisions, what skills are required to use AI responsibly, and what tools or data sources are necessary to produce a reliable result.
When AI is mapped to those capabilities, it becomes part of how the organization operates; when it is layered on top of disconnected processes, it tends to create more output without necessarily creating better outcomes.
Treat data access as a risk design problem
Data access is one of the clearest places where AI changes the operating model. To make AI genuinely useful, teams often need access to information they did not previously use directly.
A marketing team may need product documentation and customer insights, a finance team may need structured operational data, and a support team may need internal knowledge, historical context, and the ability to understand patterns across systems.
The instinct to open access is understandable because AI becomes more valuable when it has more context. The instinct to restrict access is also understandable because broader access can create privacy, compliance, and security concerns. The answer is not to choose one instinct over the other but to create a more deliberate model for deciding which data can be used, by whom, and for what purpose.
In one enterprise rollout, for example, the practical answer was not to give every team access to everything or to keep AI locked inside a technical function. It was to separate lower-risk operational data from more sensitive information, then give teams enough access to work differently while limiting the potential damage if a workflow behaved unexpectedly.
One useful way to think about this is the blast radius of data. Not every dataset carries the same level of risk, and not every AI use case deserves the same level of restriction. Some information can be made more accessible because the potential damage is limited if something goes wrong, while other information, especially personally identifiable information or sensitive customer data, requires much tighter controls.
This approach allows teams to experiment where the risk is lower while preserving stronger governance where the business truly needs it. The goal is not to make security lighter, but to make it more precise so the company can move faster without losing control of the environments, data, and workflows that matter most.
Build verification into the workflow
Verification is where many AI strategies either become scalable or begin to stall. AI systems can produce work that looks polished but is incomplete, inaccurate, off-brand, or noncompliant, and while human review can absorb some of that risk in the early stages, it does not scale well once AI becomes embedded in daily operations.
I have seen this most clearly in technical teams, where AI can accelerate software development only if there is a reliable way to evaluate the quality, security, and accuracy of what gets produced. Without that verification layer, teams may feel faster in the moment while quietly creating more review burden, more rework, and more risk downstream.
Companies need verification patterns that are designed into the workflow itself. That can include automated checks, data quality controls, approval paths, logging, observability, and clear escalation rules for outputs that should not be trusted without further review.
Leaders shouldn't treat these mechanisms as bureaucracy added after the fact. They are what allow AI to move from individual productivity aid to enterprise capability, because teams can only scale adoption when they have a repeatable way to understand whether the work being produced is accurate, appropriate, and safe to use.
Make AI adoption a leadership responsibility
AI adoption cannot be delegated to a single innovation team or AI officer while the rest of the executive team watches from a distance. Every function leader needs to understand how AI changes the work their team performs, how employees will collaborate with agents and models, and where the risks are likely to appear.
That does not mean every executive needs to become a machine learning specialist, but it does mean leaders need enough fluency to guide decisions, set expectations, and model the behavior they ask of their teams. Employees are unlikely to change the way they work if their leaders treat AI as something other people are supposed to adopt.
The cultural framing also matters because if employees hear AI adoption as a euphemism for job elimination, they will protect the current version of their role rather than explore what the next version could become. Leaders should be honest that roles will change, some workflows will disappear, and new responsibilities will emerge, while also making clear that the near-term goal is to help people do higher-quality work with better leverage.
In many cases, the shift is from doing every task manually to orchestrating systems that help do the work. That requires a willingness to work through ambiguity, which becomes more important as AI becomes more capable.
The companies that succeed with AI will not be the ones that put innovation ahead of security and they will not be the ones that wait until every risk can be eliminated in advance. They will be the ones that build enough governance, verification, and data discipline to let teams move with confidence, because within enterprise AI, control is what makes speed sustainable.
We've featured the best endpoint protection software.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit