Behind the Prompt: What’s Actually Being Managed When a Business Adopts AI

In our previous piece, we looked at what happens when AI usage grows without any structure behind it: a free-for-all phase where everyone experiments freely, followed by a crackdown phase where finance steps in and locks things down once the cost becomes impossible to ignore. That pattern isn't tied to a specific business. It's a shape we see forming across plenty of organisations adopting AI without much thought to what's underneath it.

The mechanics behind that pattern are not speculative. They're already playing out, quietly, in the way most businesses adopt AI tools today.

Using AI looks simple from the outside. Open an application, type a question, get an answer seconds later. There's no server to install, no lengthy implementation project, no obvious infrastructure to maintain. That simplicity is exactly what hides what's happening underneath it.

Every business use of AI involves decisions about the platform being used, the information it can access, the actions it's allowed to take, the model processing the request, and the cost generated along the way. None of that is visible to the person typing. All of it is the responsibility of the business that owns the outcome.

The question for most organisations isn't really whether employees should use AI. It's whether the business can see, secure, and manage how AI is being used before that usage becomes too widespread to manage properly.

Access Isn't the Same as Adoption

Not all AI use looks the same, even when it gets described the same way.

An employee might use a personal AI subscription to draft an email. A company might switch on Microsoft 365 Copilot for a few departments. A development team might build an internal tool on top of an AI model through an API. Another business might deploy an AI agent that connects directly to SharePoint, email, a CRM, or a customer service platform.

All of these get called "using AI." None of them carry the same operational weight. A standalone writing assistant might only ever see what an employee types into it. An enterprise copilot can pull information from someone's actual work environment. An AI agent can search records, generate documents, update systems, or message customers on its own.

As AI gains access to more of the business, the management requirement grows with it. Somewhere, someone needs to know which platforms are in use, who has access to them, what information they can reach, what actions they're allowed to take, how their output gets checked, and how usage and cost are being tracked. Without that visibility, AI adoption happens one application and one employee at a time, rather than as something the business is actually steering.

The Model Nobody Chose

Not every task needs the most capable model available, and most businesses never stop to ask which model is actually handling a given request.

Some work genuinely needs strong reasoning, a large context window, or the ability to work across complex documents. Plenty of other work, straightforward summarising, formatting, simple classification, doesn't. For businesses building anything custom on top of AI, model choice affects response quality, speed, cost per request, context limits, and even which security and compliance options are available.

There's also a distinction worth being clear on: choosing a model is different from choosing a product. An employee using a packaged tool like Copilot doesn't get to pick which model handles their request. The decision that matters there is which platform gets approved and under what licence and data terms. For custom AI workloads, businesses have far more control. Tasks can be routed to different models, usage limits can be set around expensive workloads, and changes can be tested before anyone downstream feels them.

Left to default settings and whatever's already open, model selection just happens. Treated as an architectural decision, it becomes something the business actually controls.

The Data Walking Out the Door

Every prompt is a data event, whether anyone treats it that way or not. Information submitted to an AI system has to be processed somewhere, and what happens to it next depends on the product, the account type, and the provider's own agreement.

Enterprise accounts often come with meaningfully stronger protections than consumer ones. Microsoft, for example, states that prompts and generated content processed through Azure-hosted models aren't made available to other customers or used to train foundation models without the customer's permission. That's a real distinction, but it's not universal, and some stateful features can still retain information depending on configuration.

This is why "never put company data into AI" isn't a useful policy on its own. It's too broad to apply and too vague to enforce. A more workable approach defines which platforms are approved, which account types employees are required to use, what categories of information can be submitted freely, what needs extra approval first, and what should never go in at all. A client contract, a patient record, an employee file, and a public marketing draft don't carry the same sensitivity, and a policy that treats them identically isn't really protecting anything. The goal isn't to slow useful AI use down. It's to stop individual employees from unknowingly making data governance calls on behalf of the whole business.

The Risks Hiding in Plain Sight

The risk changes shape entirely once an AI tool stops just generating text and starts connecting to actual business systems: email, calendars, SharePoint, OneDrive, customer records, financial platforms, project management tools, internal databases.

Those connections are exactly what make AI genuinely useful at scale. They're also what raises the stakes of getting the configuration wrong. An AI tool that drafts an email for someone to review has limited authority. An AI agent that can pull confidential files and send messages on its own carries a different level of risk entirely, and it deserves a different level of scrutiny.

The same least-privilege principle already applied across every other part of a business's IT environment applies here too: give the tool access only to what it needs, separate read permissions from write permissions, require human approval for anything sensitive, and review access again whenever the use case changes. This matters more than it might seem, because AI systems often process content nobody has vetted. Prompt injection, where instructions are buried inside a document, webpage, or email specifically to manipulate an AI system's behaviour, is a risk category OWASP identifies as significant, particularly for tools that can reach private data or trigger other connected actions. The more authority an AI application is given, the more that access needs to be tested and reviewed, not just granted and forgotten.

Policy as the Missing Safety Net

A written AI policy is useful, but it's only one piece of governance, not the whole thing. Real governance means the business can actually answer a short list of questions: who approves new AI tools, who owns each one once it's live, who checks whether it's performing as intended, who reviews the security and privacy risk, and who's responsible when it gets something wrong.

NIST's AI Risk Management Framework structures this around four ongoing functions: govern, map, measure, and manage. The framing is worth borrowing even without adopting the full framework, because it makes an important point. Governance isn't a document finished once at the start of a project. It's something that continues for as long as the tool is in use.

For a small or mid-sized business, this doesn't need to become a formal compliance program to be effective. A working version can start small: a register of which AI tools are actually approved, a named owner for each one, basic risk classifications, clear rules around sensitive information, a human review step where it matters, an approval process for anything new, and a periodic check on access, cost, and performance. That's enough structure to keep adopting AI without leaving every decision to individual judgement.

The Bill That Arrives Too Late

AI costs rarely show up in one place. Per-user subscriptions, API consumption, cloud infrastructure, storage, integrations, development time, and third-party tools can all be contributing to the same total, and a business can know exactly what it spent without understanding what actually produced that number.

That gap, between seeing the bill and understanding it, is the difference between billing visibility and real cost management. Useful reporting connects spend to the platform being used, the team or department behind it, the specific application or agent, the model selected, the volume of requests, and ideally, the business value it's actually producing. Without that context, a rising bill tends to trigger an all-or-nothing response: cut access, block a platform, shut a project down. With that context, the response can be targeted instead. Maybe one workflow is running on a model that's overkill for the task. Maybe a project nobody's used in months is still quietly generating charges. Maybe one team is getting real time savings out of a tool while another has barely touched it.

The goal isn't just spending less. It's knowing whether the spend is actually earning its place.

What Managing This Actually Looks Like

None of this means businesses need to slow AI adoption down. From our perspective, it means AI needs the same operational discipline as every other part of the technology environment.

That starts with visibility. Which platforms are being used? Who has access to them? What information can they reach? What actions can they take? What are they costing? And is anyone actually checking whether they're still delivering value?

For most businesses, this doesn't need to begin with a huge governance program. It can start with getting those basics under control and building from there.

This is also where we see the role of an MSP becoming increasingly important. AI touches far more than the application itself. It crosses cloud environments, identity and access, cybersecurity, data governance, vendor management, licensing and cost control. Managing those pieces properly is what allows a business to use AI with confidence instead of simply hoping the right controls are already in place.

Our role isn't to decide how a business should use AI. Those judgement calls still belong to the business: where AI makes sense, what information is too sensitive, which outputs need human review, and what level of risk is acceptable.

Our job is to make those decisions work in practice.

Where We Stand

At Affinity MSP, we don't see AI as something businesses should be afraid of, and we don't think the answer is to lock it down simply because it introduces new risks.

We use AI ourselves. We see the value in it. We also see how quickly it can spread across a business before anyone has really stopped to look at what's happening underneath.

That's why our position is fairly simple: businesses should be able to adopt AI without losing visibility or control.

That means giving people room to experiment, while still knowing which tools are in use, what they can access, how they're secured, what they're costing and who is responsible for them.

We've seen the same pattern play out with other major technology shifts. Cloud adoption brought enormous benefits, but it still needed identity management, security, governance and cost control behind it. AI is no different. The technology has changed, but the need to manage it properly hasn't.

The businesses we think will get the most out of AI aren't necessarily the ones moving the fastest. They'll be the ones that can keep moving without having to slam on the brakes later.

That's ultimately where we see our role.

Not as the people standing between businesses and AI, but as the people making sure the technology underneath it is secure, manageable and sustainable enough for them to keep using it on their own terms.