Your AI Needs Clear Limits and Someone Accountable

Artificial intelligence (AI) can help your company do useful work. Your company still needs control over its actions. That means clear permissions, evidence of each important action, and someone responsible for continued operation.

An AI model uses learned patterns and supplied information to produce answers.

For a founder or operations leader, the question is practical. Who decides what AI can change? Who checks the result? Who takes responsibility when the process fails?

What Nadella asks companies to control

On October 10, 2026, Satya Nadella published an article about models as insider risks. He argues that companies must separate model capability from authority over actions. His recommendations include independent controls, limited permissions, reliable action records, containment, testing, and incident disclosure.

He also warns that a model's explanation does not provide dependable proof of its behavior. Another model can help with testing. It does not remove the need for independent controls. Read Nadella's article.

Our business conclusion is direct: companies need to define authority before they give AI access to important work. A useful recommendation and permission to act are separate decisions. The system must preserve that separation throughout the process.

Make the limits part of the process

An AI agent uses a model and software tools to perform tasks. Those tools can connect a recommendation to a real business action.

That connection needs explicit rules. Decide which records the agent can read. Decide which actions it can request. Decide which changes require a person. Give the agent only the permissions its task requires.

Put those checks in software outside the model. An instruction to follow company policy does not itself enforce company policy. The software must check permission before it allows an action. The model must not change that check or approve its own exception.

Use rule-based software for decisions with exact conditions. For example, compare an order amount against a spending limit. Use human judgment when an exception needs business context. This division keeps responsibility clear without adding approval to every minor task.

An illustrative supplier order

Consider a purchasing team that needs to replenish stock. This example illustrates a proposed process. It does not describe a verified Chiri customer deployment.

The agent reads approved inventory and supplier records. It recommends an order quantity and identifies the records behind its recommendation. It submits the proposed order to a separate software check.

That check confirms the approved supplier, required fields, and spending limit. It also checks for an existing order. If the proposal passes, the process follows the company's approval rules. If it fails, the system stops the action and asks a person to review it.

Suppose a supplier document contains instructions to change payment details. The document provides business information. It does not grant authority to change bank records. The agent's purchasing permission must not extend to that separate task.

The action record must show the request, checks, approval, and result. It must also show a refusal or failure. A person must have a way to stop further actions while the team investigates.

This process lets people evaluate a specific order. They can inspect the evidence and the rules that controlled the action. They do not need to accept the agent's account as the only record.

Keep responsibility after deployment

Deployment means putting the system into use.

The first successful order does not finish the work. Assign an owner for the process and an owner for its technical operation. Define how they handle failures and how they report incidents to affected people.

Test the process when its permissions, connected applications, or model change. Include missing records, duplicate requests, unauthorized instructions, and failed connections. Check whether the system refuses actions outside its limits.

Also test the recovery steps. If an order fails halfway through, establish what the system actually changed. Confirm that a repeated request does not create an unwanted second order. Document who can authorize another attempt.

These operating duties belong in the engagement from the start. A team needs a clear answer when the original builder leaves. Continued support must cover the system that performs the work, including its changing connections and controls.

How Chiri approaches this work

Chiri is an AI managed service provider built like a software company. A managed service provider delivers systems and supports their continued operation. We build company-specific applications around business processes and work with your existing software. Explore Chiri's approach.

Chiri Brain provides the shared platform beneath those applications. This platform is the software foundation that supports the applications. Brain includes model controls and connections to other applications.

Brain also includes permissions and records for selected actions. These components support the work around the model. Each project must confirm which actions its records cover. Explore the platform.

The engagement starts with a business problem. Our engineers and operators work with your team to understand the process and build the application. Chiri continues its operational responsibility after that initial team steps back. See how an engagement works.

For each project, the scope must identify the required controls and acceptance checks. A platform capability alone does not establish that every application meets every requirement. The process, implementation, and operating agreement must support the intended use.

Five questions before AI takes action

Use these questions when you review a proposed AI deployment:

1. What can the agent read and change, and where does software enforce those limits?
2. Which actions require human approval, and who can grant it?
3. Can we inspect action records without relying on the model's explanation?
4. Who can stop the process, investigate a failure, and notify affected people?
5. Who maintains the controls and tests changes after deployment?

Ask for a demonstration using a failed or unauthorized request. That shows how the system handles its limits. It also gives your team a concrete basis for acceptance.

Start with one business process and define a useful outcome. Then define the authority, evidence, and continued support that outcome requires. Talk with Chiri about the work you want AI to do.