{"id":14120,"date":"2026-10-07T15:18:48","date_gmt":"2026-10-07T09:48:48","guid":{"rendered":"https:\/\/gapstars.net\/tech\/?post_type=resource&p=14120"},"modified":"2026-10-07T15:24:48","modified_gmt":"2026-10-07T09:54:48","slug":"scaling-ai-without-scaling-risk","status":"publish","type":"resource","link":"https:\/\/gapstars.net\/tech\/resource\/scaling-ai-without-scaling-risk\/","title":{"rendered":"Scaling AI Without Scaling Risk: Engineering Lessons from Our Latest Data & AI Guild"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

AI governance becomes interesting when it moves from policy into production. What happens when agent access outgrows the data behind it, platform updates change behaviour, or an automation that looks inexpensive in development becomes costly at scale?<\/span><\/p>

These were some of the questions explored in the latest <\/span>Gapstars Data & AI Guild<\/span>, our bi-monthly learning initiative for practical knowledge-sharing across data and AI. For Session 9, <\/span>Sachintha Senanayake, Senior GenAI Engineer<\/span>, shared lessons from a recent enterprise rollout of Microsoft 365 Copilot, focusing on the engineering decisions, failure modes and governance challenges that emerge in real-world use.\u00a0

<\/span><\/p>

1. Separate AI access from the right to build<\/span><\/h2>

One of the more useful design decisions in the rollout was not treating AI access as a binary permission. Users were divided into three broad groups: knowledge workers, AI Champions and builders. Knowledge workers used AI in their day-to-day work and, as they became more familiar with it, started identifying processes that could potentially be automated.<\/span><\/p>

AI Champions created the bridge between those observations and technical implementation. Often closer to the operational context of a department, they helped turn opportunities into structured use cases before builders implemented the ones that justified engineering effort. In practice, this created a discovery pipeline from <\/span>AI usage to process insight, use case and technical implementation<\/span>.\u00a0<\/span><\/p>

The value is not simply restricting who can build agents. It means the organisation does not rely solely on engineers to discover automation opportunities. The people closest to the work identify where friction exists, while technical teams retain responsibility for how those ideas are implemented. At the same time, more advanced build and publishing capabilities remain controlled rather than being distributed indiscriminately.

<\/span><\/p>

2. Agent access and data access are different boundaries<\/span><\/h2>

One of the exercises during the session exposed a subtle configuration problem. Imagine an agent built around finance information: the underlying data is restricted to the finance team, but the agent itself is shared across the organisation. The data permissions may still technically be intact, but the sharing scope of the agent is now wider than the intended scope of the information behind it.\u00a0<\/span><\/p>

This matters because teams naturally think about access control at the data layer, while agents introduce another boundary entirely. Engineers now need to reason not only about what the agent can access, but who can access the agent, which connectors it can call and whether all of those scopes make sense together.<\/span><\/p>

Those scopes do not necessarily need to be identical. The important point is that widening one of them should be an explicit architectural decision rather than an accidental consequence of a sharing setting. As agent ecosystems grow, scope alignment becomes a governance problem in its own right.<\/span><\/p>


3. Platform drift is now part of production risk<\/span><\/h2>

One of the strongest examples from the session involved agent behaviour changing even when the team had not deliberately changed the agent. An automation relied on generated scripts to produce consistent output and worked as expected until changes in the underlying platform altered that behaviour. From the team’s perspective, the application had effectively changed underneath them.\u00a0<\/span><\/p>

That introduces a different kind of production risk. Teams may control their own configuration while still depending heavily on model updates, orchestration layers, connectors, agent-building interfaces, generated code and other vendor-controlled behaviour. Platform drift therefore becomes something that engineering teams need to design for rather than treat as an edge case.<\/span><\/p>

One response discussed during the session was bringing agent definitions and configuration into source control wherever possible. If behaviour changes unexpectedly, the team needs enough visibility to determine whether the cause was its own configuration, a platform update, model variance or a change in connected data. Conventional software engineering practices become particularly valuable here because AI systems introduce additional components that teams do not fully control.

<\/span><\/p>

4. Some governance failures cannot be solved with admin controls<\/span><\/h2>

Another exercise showed an agent whose custom instructions contained sensitive legal information directly inside the prompt. Tenant policies, data loss prevention rules and connector restrictions can control a lot of what moves through a system, but they cannot necessarily prevent someone from putting inappropriate information directly into an agent’s <\/span>system prompt<\/span>.\u00a0<\/span><\/p>

The recommended pattern was to keep sensitive material in appropriately permissioned data sources rather than embedding it directly in prompt instructions. More importantly, the example showed why AI governance cannot be reduced to a list of platform settings. Some risks sit in configuration, others in architecture or user behaviour, and some can only be reduced through training and review.<\/span><\/p>

A stronger governance model therefore needs several layers working together: <\/span>technical controls, engineering practice, organisational review and informed users<\/span>. The point is not redundancy for its own sake; each layer catches a different class of failure.

<\/span><\/p>

5. Model choice can become a legal and architectural decision<\/span><\/h2>

A question during the session highlighted another technical consideration that is easy to miss. When an additional model provider became available through the platform, enabling it could potentially change where data was processed. What looked like a simple model-selection decision therefore became a legal and architectural one.\u00a0<\/span><\/p>

The governance process included reviewing provider agreements and data-processing conditions before deciding how the capability should be enabled. In enterprise environments, selecting a model can implicitly mean selecting another subprocessor, processing location, contractual dependency or regulatory boundary.<\/span><\/p>

That means model choice cannot always be treated purely as a question of quality, latency or cost. Two models available through the same interface may look interchangeable from a user’s perspective while representing very different architectures behind the scenes.

<\/span><\/p>

6. Cost needs to be tested like performance<\/span><\/h2>

One agent discussed during the session looked technically viable but was projected to cost around <\/span>$12,000<\/span> if it ran continuously in production. Crucially, that was identified during testing rather than after deployment.\u00a0<\/span><\/p>

Development usage can hide the economics of agentic systems. A workflow that looks inexpensive when triggered a handful of times may behave very differently once it runs continuously, invokes multiple model calls, processes larger contexts, calls external systems or scales across a large user base.<\/span><\/p>

That makes cost another non-functional requirement. Alongside functional testing, teams need to run representative production workloads, measure actual consumption and forecast that usage against expected volume before deciding whether an automation still makes sense at scale.

<\/span><\/p>

7. Productivity is not the same as business return<\/span><\/h2>

The session also made an important distinction between individual productivity gains and organisation-level value. Time savings often appear first: people summarise meetings faster, draft documents faster and process information more efficiently. But those improvements alone do not prove the wider business case.\u00a0<\/span><\/p>

The rollout viewed value as a progression from <\/span>adoption to behavioural change, workflow improvement, better judgement and ultimately business outcomes<\/span>. The further up that chain you move, the harder measurement becomes. Adoption can be pulled from a dashboard; business impact usually requires baselines, cross-functional input and enough time to understand whether AI is materially changing how work gets done.<\/span><\/p>

The more interesting opportunity can appear later. As users become more comfortable with AI, they begin identifying larger automation opportunities that were not obvious at the start. This is where the earlier knowledge worker\u2013AI Champion\u2013builder model becomes valuable again: individual usage becomes a discovery mechanism for broader process improvement.<\/span><\/p>


The bigger lesson<\/span><\/h2>

The difficult part of enterprise AI is not giving people access to a model. It is managing the new boundaries that appear around it. An agent has a sharing boundary, its data has another, its connectors add more, and the model provider may introduce a different processing boundary entirely. At the same time, the platform can change independently of your own code, while the cost profile of an agent can shift dramatically as usage scales.\u00a0<\/span><\/p>

That is why AI governance increasingly looks less like a standalone policy exercise and more like systems engineering. Teams need visibility into configuration, clear ownership, risk-based review, versioning where possible, cost modelling, appropriate data boundaries and enough organisational structure to catch the things platform controls cannot.<\/span><\/p>

The objective is not to slow teams down. It is to make sure that as AI systems become more capable, the organisation’s ability to understand and control them scales with them.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

5 no-regret moves to stay in control of AI inside your org: classify risk, build a registry, guardrail, and more.<\/p>\n","protected":false},"featured_media":14127,"template":"","meta":{"_acf_changed":false,"content-type":""},"resource-category":[77],"class_list":["post-14120","resource","type-resource","status-publish","has-post-thumbnail","hentry","resource-category-blog"],"acf":[],"_links":{"self":[{"href":"https:\/\/gapstars.net\/tech\/wp-json\/wp\/v2\/resource\/14120","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gapstars.net\/tech\/wp-json\/wp\/v2\/resource"}],"about":[{"href":"https:\/\/gapstars.net\/tech\/wp-json\/wp\/v2\/types\/resource"}],"version-history":[{"count":6,"href":"https:\/\/gapstars.net\/tech\/wp-json\/wp\/v2\/resource\/14120\/revisions"}],"predecessor-version":[{"id":14128,"href":"https:\/\/gapstars.net\/tech\/wp-json\/wp\/v2\/resource\/14120\/revisions\/14128"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/gapstars.net\/tech\/wp-json\/wp\/v2\/media\/14127"}],"wp:attachment":[{"href":"https:\/\/gapstars.net\/tech\/wp-json\/wp\/v2\/media?parent=14120"}],"wp:term":[{"taxonomy":"resource-category","embeddable":true,"href":"https:\/\/gapstars.net\/tech\/wp-json\/wp\/v2\/resource-category?post=14120"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}