The business wants to use AI now. Security must protect data and reduce risk. IT leadership needs to be able to say yes to the right things and no to the rest without turning every new application into a separate negotiation.
AI does not primarily create a tool problem. It creates a management problem.
The same AI service can be used to improve a public text, analyze an internal document, write code, or process customer information. The service may be the same. The purpose, the data, and the consequences are not.
This is not just a security goal. It is the prerequisite for the company to scale its use of AI without turning every new application into a new risk project.
Therefore, it is not enough to choose between a general ban and free access. The company must be able to decide what a "yes" to AI actually means and make that decision work in practice.
In this article, you will get a method to:
- Make AI a management decision rather than a tool choice
- Set different frameworks for users, data, and actions
- Translate a policy into enforcement and documentation
- Organize exceptions, ownership, and ongoing operations
A ban does not solve the need. A policy does not solve the enforcement itself.
A general ban may look simple on paper. But when employees experience that AI solves real tasks faster, the need does not disappear. The risk is that some of the usage instead moves to private accounts, unvetted services, and solutions that IT has no insight into.
The opposite extreme is not useful either: opening up a category of tools and leaving the assessment to the individual employee.
An AI policy is necessary. It can describe principles, responsibilities, and boundaries. But it cannot, on its own, see which services are being used, distinguish between a corporate account and a private account, or stop an action that violates the rules.
The crucial question is therefore not whether employees have a responsibility. They do. The question is whether the employee's split-second judgment should be the company's most important security control.
The AI Act makes it more relevant, but not simpler
On August 2, 2026, the EU Commission's AI Office and national authorities began enforcing the AI Act, and the transparency requirements in Article 50 became applicable. The specific obligations vary depending on the AI system and the company's role.
For IT leadership, the point isn't that every company has the same requirements. The point is that AI usage must increasingly be explainable, manageable, and documented. This makes governance an operational task – not just a legal one.
5 simple decisions that make controlled AI rollout possible in practice
A good AI strategy doesn't start with a list of platforms. It starts with five decisions that business, security, and IT can agree on together.
1. Which use cases will we actively support?
Start with the work, not the technology. Is the goal to speed up research, improve internal analysis, support developers, or handle customer inquiries better?
Once the use case is clear, it becomes possible to assess which users, data, and frameworks are appropriate for it. AI thus becomes a prioritized business opportunity rather than a collection of random tools.
How Itavis solves it
1. Start with one or two concrete AI use cases that the business is already requesting.
2. Map out the task, the users, the affected data, and the desired outcome. Combine this with visibility into which AI services are actually being used.
3. Consolidate these decisions into a use-case registry, where each use case is classified as approved, conditionally approved, or not approved.
Output: A prioritized overview of the AI use cases the organization will actively support – and the conditions that apply to them.
2. Which data and actions require restrictions?
Access to an AI service is not the same as permission for every type of use.
For example, you might allow general text processing but restrict file uploads. You might allow an approved work account but not private accounts. And you can have different frameworks for employees handling different types of data.
A useful decision distinguishes at a minimum between user or group, purpose, account, action, and data category. This is more precise than treating the entire AI category as a single risk.
How Itavis solves it
1. Define which user groups, corporate accounts, and services are permitted for each application.
2. Distinguish between standard access and higher-risk actions, such as logging in with a personal account, uploading files, downloading, or sharing specific data types.
3. Translate your company's data categories into concrete rules. Solutions like Application Control and DLP can be used to manage access, tenants, actions, and identified types of sensitive data.
Output: A control matrix that links users, accounts, services, actions, and data categories to the desired policy.
3. How do we enforce the decisions?
A rule only becomes a control when it functions exactly where users and data interact.
If a policy change requires manual coordination across several separate systems, it becomes slower to implement and harder to keep consistent. Every additional control plane increases the risk that rules will gradually drift apart.
The goal is not to use as much technology as possible. The goal is to translate management decisions into differentiated access and protection without creating a new, isolated operational task.
How Itavis solves it
1. Translate the control matrix into consistent rules across users, services, actions, and locations—without manual changes in multiple systems (this is significantly simplified with a centralized Zero Trust platform).
2. Start with monitoring or alerting where the consequences are still uncertain. Test the rules on a limited user group before enforcing them broadly.
3. Assess whether the control should only apply to access to the AI service or also to the interaction itself. For proprietary AI applications and agents, it may be necessary to control prompts, responses, API calls, and agent actions.
Output: A tested set of rules with documented expected outcomes, an approved rollout, and a plan for adjustments.
4. What documentation do we need?
It is not enough to simply show what is written in the policy. You must be able to form an accurate picture of what is actually happening.
This could, for example, include an overview of services used, classification of approved and unapproved usage, relevant data flows, and a record of the rules that were in effect. Not for the sake of documentation itself, but to be able to follow up, investigate incidents, and make future decisions based on better information.
How Itavis solves this
1. Agree in advance on which questions the documentation needs to answer. This could include which services are being used, who is using them, which rules apply, and what incidents or breaches have been recorded.
2. Use Cato's dashboards, events, and activity data to create an operational view of usage and enforcement.
3. Establish a simple review format that shows trends in usage, deviations, policy changes, and pending decisions – without making reporting an end in itself.
Output: A recurring basis for decision-making that IT and security can use for follow-ups, incident management, and strategic planning.
5. Who owns the exceptions and ongoing operations?
AI usage does not stand still. New services and features emerge, and the business discovers new needs.
Therefore, it must be clear who evaluates new use cases, who implements changes, who approves time-limited exceptions, and who monitors actual usage. Without this, temporary special rules quickly become permanent, and control loses its consistency.
How Itavis solves this
1. Clearly define ownership: The business owns the need, the organization owns the risk appetite, and IT/security approves the framework.
2. Assign every exception an owner, a justification, a defined scope, and an expiration date. An exception without an expiration date quickly becomes a permanent special rule.
3. As a partner, we often take on the agreed technical operational responsibility for policy changes, alerting, and ongoing adjustments, while consolidating new needs and deviations for the customer to decide upon.
4. Review new services, actual usage, recorded breaches, and exceptions that need to be extended, modified, or closed on a regular basis.
Output: An operating model with clear decision-making rights, controlled exceptions, and a set rhythm for changes and follow-ups.
Control should make responsible AI easier
Control is often described as the thing that slows down innovation. In practice, a clear, operational model can make it easier to say yes.
When the framework is understandable and enforceable, the business avoids having to start a debate on principles every time a new need arises. IT can reduce manual workarounds. And employees get clearer boundaries than a long policy they have to interpret themselves under time pressure.
The goal is not to move from freedom to restriction. It is to move from ad-hoc decisions to repeatable decisions.
Here are four quick signs that the gap between policy and operations is too wide:
- You have a list of approved solutions, but no overview of the services actually being used.
- A tool is either completely open or completely closed because you cannot distinguish between account, user group, and action.
- The rules rely heavily on individual employees correctly assessing data and purpose themselves.
- You can describe the desired rule, but struggle to show what applied to a specific user and situation.
If several of these points apply, the policy is not necessarily bad. But it likely lacks an operational layer to support it.
Four requirements for the control layer before you choose a solution
Before the conversation turns to technology, you should agree on what the control layer needs to be able to do:
- Create context: Link usage to user, group, account, service, action, and data.
- Enforce in a nuanced and granular way: Allow relevant use cases without opening up to all users, accounts, and data flows.
- Provide actionable evidence: Demonstrate which rules applied, what was permitted or blocked, and when it occurred.
- Maintainable over time: Make changes, exceptions, and follow-ups manageable without constant coordination between siloed systems.
These requirements are more important than a feature list. They allow you to evaluate any solution based on the management decision it is intended to support.
The method: From decision to operating model
It doesn't have to start with a massive program. Begin with one or two AI use cases that the business is already asking for, and work through the five decisions in a disciplined manner.
First, map out the specific task and the data it involves. Then, decide what is permitted, restricted, or prohibited, and for whom. Translate the decision into controls that can be implemented consistently. Finally, agree on what documentation you need and how you will handle the next change.
That order is important. Technology should support the chosen method; it should not define the company's risk appetite or goals.
A technical control model does not replace data classification, identity management, risk assessments, training, or management responsibility. However, it can make a significant part of governance enforceable, visible, and operational.
What IT leadership can take forward in the organization
The company does not have to choose between uncontrolled AI and stagnation.
It can actively support specific use cases while setting different frameworks for users, data, and actions. But this requires that governance does not stop at an ambition or a policy. It must be connected to enforcement, documentation, and clear operational responsibility.
This is the conversation that an IT manager, CIO, or CISO can take forward:
- Which AI use cases do we actually want more of?
- What should be possible, and what should be restricted?
- How will we see that our decisions are working?
- Who is responsible when the requirements change?
Once the answers are aligned, the organization can begin using AI with both speed and direction, without IT losing control along the way.
