How should a Business Approve New AI Tools ?

Do not approve the tool. Approve the use.

A business should approve new AI tools by approving specific use cases, not tools in the abstract.

That distinction matters.

Asking “should we approve this AI tool?” is often too broad. The same AI tool may be low risk when used for internal brainstorming, but high risk when used with confidential customer information, legal drafting, financial analysis, employment decisions, source code, or customer-facing advice.

The better question is:

Is this use of this AI tool acceptable, with this data, for this purpose, under these conditions?

That is the foundation of practical AI tool approval.

An AI approval process should identify the tool, vendor, use case, business owner, data involved, output type, risk level, controls, human review requirements, approval status, evidence, known gaps, and review date.

The goal is not to block AI adoption. The goal is to make AI use visible, proportionate, accountable, and safe enough to operate.

Why AI tool approval is different

Traditional software approval often starts with the system.

A business identifies a product, reviews the vendor, checks cost and security, negotiates terms, configures access, trains users, and then deploys the system.

AI does not always follow that path.

AI may enter the business through a browser, personal account, private phone, code editor, meeting tool, productivity suite, plugin, or embedded feature inside an existing vendor platform. A team may begin experimenting before procurement, IT, legal, privacy, or security know the tool is being used.

AI is also different because the same tool can support many different uses.

One person may use an AI tool to rewrite internal notes. Another may use it to summarise client information. Another may use it to generate code. Another may use it to draft contract clauses. Another may use it to prepare management reporting.

The tool name may be the same.

The risk is not.

This is why AI approval must be use-case led.

For AI, the tool tells you what is available. The use case tells you what is at risk.

The main approval principle

The central approval principle is simple:

Approve AI tools for defined uses, not unlimited use.

A business might approve an AI tool:

for internal drafting only;

with public information only;

for named teams only;

for non-confidential material only;

with human review before external use;

for a limited pilot;

subject to privacy review;

subject to security review;

subject to vendor terms being confirmed;

subject to review after 90 days.

This matters because AI approval should create a clear operating boundary.

Without conditions, approval can drift. A tool approved for brainstorming may gradually be used for customer emails, confidential analysis, legal material, financial modelling, HR decisions, or production code.

That is not necessarily deliberate misuse. It is how AI adoption often spreads.

A good approval process prevents low-risk experimentation from quietly becoming high-risk reliance.

A practical AI tool approval workflow

A business does not need a heavy enterprise committee for every AI use. But it does need a repeatable process.

A practical workflow can follow ten steps.

Step 1: Capture the request

The approval process should begin with a simple request.

The request should record:

the AI tool name;

the vendor or provider;

who is requesting approval;

which team or function will use it;

the intended use case;

why the tool is needed;

whether the use is new, expanded, or already happening informally.

This first step is important because it turns informal AI interest into a visible governance record.

A request does not need to be complex. For small and mid-sized businesses, a short form may be enough.

The purpose is to make sure the business understands what is being proposed before the tool becomes part of everyday work.

Step 2: Define the use case

The use case is the most important part of the approval.

“Use ChatGPT for productivity” is too vague.

“Use ChatGPT to draft internal marketing ideas using only public information” is more useful.

“Use Microsoft Copilot to summarise internal sales meeting transcripts and identify follow-up actions” is also more useful.

The use case should explain:

what the AI will do;

who will use it;

what task it supports;

what information will be entered;

what output will be produced;

who will rely on the output;

whether the output is internal or external;

whether the output influences decisions.

This step prevents the business from approving a tool without understanding how it will actually be used.

Step 3: Identify the data involved

This is where many AI approval decisions become serious.

A business must ask what data will be entered into, uploaded to, processed by, or accessed by the AI tool.

Data types may include:

public information;

general internal information;

customer information;

personal information;

employee information;

financial information;

legal material;

contracts;

health or sensitive information;

source code;

security information;

commercial secrets;

board or strategy material;

client confidential information.

The data question should be asked before approval, not after an incident.

The approval decision may change completely depending on the data.

A tool may be acceptable for public information and internal drafting, but unacceptable for personal information, confidential client data, credentials, regulated information, or source code.

The business should also ask:

Will prompts be stored?

Will uploaded files be retained?

Can the vendor use inputs or outputs for model training?

Can data be deleted?

Where is the data processed or stored?

Can the business configure retention settings?

Are users accessing the tool through business accounts or personal accounts?

Are audit logs available?

Can access be managed when someone leaves?

If the business does not know what happens to the data, that uncertainty should be recorded as a gap.

Approval should not manufacture confidence where evidence is missing.

Step 4: Review the vendor and deployment model

AI tool approval is partly a vendor risk decision.

The business should understand who provides the tool and how it is deployed.

The tool might be:

a public AI service;

an enterprise SaaS product;

an AI feature inside an existing platform;

a browser extension;

a mobile app;

a coding assistant;

a private cloud deployment;

an on-premise or self-hosted model;

a custom model or API-based service.

The approval should consider whether the deployment model matches the use case and data sensitivity.

This is where the cloud versus on-premise question appears.

The question is not whether cloud AI is always bad or on-premise AI is always better. That is too simple.

The better question is:

Does the deployment model match the data, use case, controls, and risk tolerance?

Cloud AI may be appropriate for low-risk drafting, public information, or tools with strong enterprise controls and contractual protections.

A private deployment, dedicated environment, controlled tenancy, or on-premise model may be more appropriate where the use involves sensitive personal information, confidential client data, trade secrets, source code, regulated data, high-impact decision support, or strict contractual obligations.

On-premise or private deployment can reduce some risks, but it also creates new responsibilities: infrastructure, patching, model management, monitoring, performance, security, and governance.

The approval process should avoid slogans. It should match the deployment model to the risk.

Step 5: Assess the business risk

The business should assess what could go wrong.

The risk assessment does not need to be complex, but it should be honest.

Common AI risks include:

privacy risk;

confidentiality risk;

cybersecurity risk;

inaccurate or hallucinated output;

misleading customer communication;

legal or regulatory exposure;

bias or unfair treatment;

poor-quality decision support;

vendor dependency;

loss of intellectual property control;

reputational harm;

operational reliance on outputs no one can verify.

The risk assessment should also consider the verification gap.

AI can help a business produce work faster than the business can understand, test, or vouch for it. That is especially important when the output is legal, financial, technical, security-sensitive, customer-facing, or decision-influencing.

The approval process should ask:

Can the business verify the output?

Who is qualified to review it?

What happens if the output is wrong?

Could the output be relied on by customers, employees, directors, regulators, or business partners?

Could the tool expose sensitive information?

Could the use create obligations the business does not understand?

A low-risk use may need only light controls.

A higher-risk use may need formal review, restricted access, expert validation, or rejection.

Step 6: Define controls and conditions of use

Approval should rarely mean “use however you like.”

Most AI approvals should include conditions.

Conditions might include:

do not enter personal information;

do not enter client confidential information;

do not enter passwords, secrets, or credentials;

use only approved business accounts;

do not use for final legal, financial, employment, health, or safety decisions;

human review required before customer-facing use;

legal review required before contract use;

security review required before production code use;

outputs must be fact-checked;

outputs must not be copied into published material without review;

tool must be reviewed every 90 days;

vendor terms must be rechecked before expansion.

Conditions make approval practical.

They allow the business to approve useful AI use without pretending every use carries the same risk.

Step 7: Decide the approval outcome

Approval should not be limited to yes or no.

A useful approval process should allow several outcomes:

approved;

approved with conditions;

approved for a limited pilot;

approved for internal use only;

approved for specific teams only;

approved only with public information;

more evidence required;

paused pending privacy or security review;

rejected;

prohibited for this use case.

This is important because many AI tools are not simply good or bad.

They may be appropriate for one use case and inappropriate for another.

The approval record should state:

what was approved;

who approved it;

why it was approved;

what evidence was considered;

what conditions apply;

what gaps remain;

when it must be reviewed.

Approval should create a record, not just permission.

Step 8: Add the use case to the AI usage register

Once a decision is made, the approved or rejected use should be recorded in the AI usage register.

The register should include:

tool name;

vendor;

use case;

business owner;

team or function;

data types;

output audience;

decision impact;

risk level;

approval status;

conditions of use;

evidence and rationale;

known gaps;

review date;

incidents or lessons learned.

This connects the approval decision to ongoing governance.

The register should not be a static list of tools. It should be a living record of AI use cases.

This matters because use cases change.

A tool approved for internal drafting may later be used for customer advice. A tool approved with public information may later be used with confidential data. A tool approved for low-risk support may later influence business decisions.

When the use case changes, the approval may need to change too.

Step 9: Communicate the decision

An approval decision is only useful if people understand it.

The business should communicate:

whether the tool is approved;

what use case is approved;

who may use it;

what data may be used;

what data is prohibited;

what review is required;

what conditions apply;

who owns the use case;

where questions or incidents should be raised.

For small businesses, this can be simple.

The goal is not to generate policy theatre. The goal is to make sure people know what they can and cannot do.

A tool that is “approved with conditions” should not become a vague rumour that “AI is approved.”

Step 10: Review and monitor the use

AI tool approval should not be permanent.

AI tools change. Vendor terms change. Models change. Features change. Use cases expand. New risks appear. Employees find new ways to use the tool. Laws, standards, and customer expectations evolve.

The approval record should include a review date.

Review should also be triggered when:

the use case changes;

new data types are introduced;

the output becomes customer-facing;

the tool is used in decision support;

the vendor changes terms;

an incident or near miss occurs;

a policy changes;

a new standard or regulation becomes relevant;

the business cannot verify the output;

the tool is expanded to new teams.

Review is not a bureaucratic afterthought. It is how AI governance learns.

Cloud versus on-premise: how should businesses think about it?

The cloud versus on-premise question can become distracting if it is treated as the starting point.

It should not be.

The starting point is the use case.

The business should first ask:

What will the tool be used for?

What data will it process?

Who will rely on the output?

What could go wrong?

What controls are required?

Then the business can ask whether a public cloud tool, enterprise SaaS tool, private cloud deployment, dedicated environment, on-premise system, or custom model is appropriate.

For many small and mid-sized businesses, cloud-based AI tools may be the practical starting point. They are accessible, affordable, and easy to test. But that does not mean every use is appropriate.

A public AI tool may be fine for brainstorming public marketing ideas.

It may not be fine for uploading customer records, confidential contracts, source code, employee files, financial forecasts, legal advice, or security-sensitive material.

On-premise or private deployments may provide more control in some cases, but they are not automatically safer. They require expertise, maintenance, monitoring, security, and governance.

The approval process should not ask “cloud or on-premise?” in the abstract.

It should ask:

What deployment model is appropriate for this use case, data, and risk?

Approval for small and mid-sized businesses

Small and mid-sized businesses do not need heavy approval machinery.

They do need practical gates.

A small business should not need a 20-person committee to approve low-risk AI use. But it should know when a use case crosses into confidential data, customer impact, legal exposure, financial risk, security risk, employment decisions, or decision support.

A lightweight approval process can be simple:

Request the use.

Define the use case.

Identify the data.

Assign an owner.

Assess the risk.

Set conditions.

Record the decision.

Review later.

That may be enough to prevent many avoidable problems.

The key is proportionality.

Low-risk use should be easy to approve.

Higher-risk use should receive more scrutiny.

Prohibited use should be clear.

Uncertain use should create a gap, not an assumption.

Small businesses should not have to choose between doing nothing and building an enterprise governance program.

They need a practical approval process that fits how they work.

Common approval mistakes

Several mistakes appear often.

The first is approving the tool rather than the use case. This creates uncontrolled expansion.

The second is ignoring data. The data being entered often determines the real risk.

The third is relying on personal accounts. Personal accounts may lack business controls, auditability, retention settings, or access management.

The fourth is assuming vendor claims are enough. Vendor statements should be reviewed and recorded as evidence, not treated as unquestioned assurance.

The fifth is making approval permanent. AI use should be reviewed as tools, models, terms, risks, and use cases change.

The sixth is failing to record conditions. If approval is conditional, the conditions must be visible.

The seventh is not assigning an owner. Without an owner, review and accountability become unclear.

The eighth is forgetting embedded AI. AI may appear inside tools the business already uses.

The ninth is not considering output reliance. Internal drafting is different from customer advice or decision support.

The tenth is approving without evidence. Governance decisions should be explainable later.

How AgorikAI helps

AgorikAI is designed to help organisations turn AI approval from an informal decision into structured governance knowledge.

It supports the idea that businesses should approve AI use cases, not tools in isolation.

A single AI tool can support many use cases, each with different owners, data types, risks, controls, approvals, evidence records, review dates, and lessons learned.

AgorikAI helps connect those elements.

That means an approval can become part of a broader governance model:

tool;

vendor;

use case;

owner;

data;

risk;

controls;

evidence;

approval decision;

conditions;

known gaps;

review date;

incidents;

learning.

This matters because AI governance should be empirical and ontological.

Empirical means approval decisions are grounded in evidence, tested against outcomes, and improved over time.

Ontological means the system understands the key things being governed and how they relate.

For AI approval, that relationship matters. If a policy changes, which approved use cases are affected? If a vendor changes terms, which owners need review tasks? If a new data type is introduced, does the risk level change? If an incident occurs, which similar approvals need reassessment?

AgorikAI is being built to help show those relationships and turn changes into reviewable work.

The goal is not to make approval heavy.

The goal is to make safe approval easier to operate.

Practical approval checklist

Before approving a new AI tool or use case, ask:

What tool is being requested?

Who is the vendor?

What is the specific use case?

Who owns it?

Why is it needed?

What data will be entered or processed?

Will personal, confidential, legal, financial, technical, or regulated data be used?

What output will be produced?

Who will rely on the output?

Is it customer-facing?

Does it influence decisions?

Can the output be verified?

What risks exist?

What controls are required?

What evidence supports approval?

What gaps remain?

What conditions should apply?

When should the use be reviewed?

Where will the decision be recorded?

If the business cannot answer these questions, it may not be ready to approve the use.

Conclusion

A business should not approve new AI tools in the abstract.

It should approve specific AI use cases under specific conditions.

That means understanding the tool, vendor, purpose, owner, data, output, risk, controls, evidence, approval status, and review date.

The most important question is not:

“Is this AI tool good?”

The better question is:

“Is this use of this AI tool acceptable, with this data, for this purpose, under these controls?”

That is the practical foundation of AI approval.

Used well, AI can help businesses move faster, reduce manual work, improve drafting, support analysis, and unlock new capability.

But speed without visibility creates risk.

A good approval process helps the business adopt AI safely, proportionately, and with evidence.

Do not approve the tool.

Approve the use.

FAQ

Should a business approve AI tools or AI use cases?

A business should approve AI use cases. The tool matters, but the use case determines the risk. The same tool may be low risk for brainstorming and high risk for confidential data analysis or customer-facing advice.

What is the first question to ask before approving an AI tool?

Ask what the tool will be used for. A clear use case is the starting point for reviewing data, risk, controls, ownership, and approval conditions.

Can a small business use a simple approval process?

Yes. Small businesses do not need heavy enterprise processes for every AI use. They need a practical workflow that captures the use case, data, owner, risk, conditions, decision, and review date.

Is cloud AI safe for business use?

It depends on the tool, vendor, settings, data, use case, and controls. Cloud AI may be appropriate for low-risk uses, but sensitive data or high-impact use cases may require stronger controls or different deployment models.

What data should not be entered into public AI tools?

As a general rule, businesses should avoid entering personal information, confidential client data, credentials, source code, financial records, legal material, security-sensitive information, or regulated data into public AI tools unless the use has been reviewed and approved.

What does “approved with conditions” mean?

It means the AI use is allowed only within defined boundaries. For example, the tool may be approved for internal drafting only, public information only, named users only, or customer-facing use only after human review.

How often should approved AI tools be reviewed?

Approved AI use should be reviewed regularly and whenever something changes: the use case, data type, vendor terms, model behaviour, policy, controls, risk level, or business reliance on the output.