Part 2: Set the Data and Governance Boundary

There is another test that should sit alongside cost, sharing and UX: what data does this thing touch, and who owns the consequences?

This is where many AI projects become more serious than they first appear. A harmless-looking assistant can suddenly become risky if it connects to client files, HR data, financial records, project documents, contracts, CRM notes, source code, credentials, pricing models or internal methodologies. The issue is not just whether the model is "secure". The issue is whether the whole workflow respects the organisation's data rules.

This is a strong practical argument for staying inside governed productivity platforms where possible. If Microsoft 365, Google Workspace or another enterprise suite already holds the permissions, retention policies and audit controls, using AI inside that boundary may reduce risk. The assistant may inherit more of the organisation's existing governance model.

But that is only true if the implementation respects those boundaries. A poorly configured agent connected to too many sources can make oversharing worse. A broad connector can collapse useful security boundaries. A workflow that summarises "everything relevant" can accidentally surface information from the wrong client, wrong matter or wrong team.

This is why "we will just build a Streamlit app" can be misleading. A prototype can be simple. A governed internal AI application is rarely just simple.

The moment it touches meaningful business data, you may need SSO, role-based access control, row-level permissions, audit logs, encrypted storage, secrets management, data retention rules, monitoring, incident response and a clear owner. You also need to decide whether embeddings, cached prompts, model outputs and evaluation datasets count as governed data. Usually, they should.

Security Is Not Just Login

It is easy to reduce security to authentication: "users log in with Microsoft, so we are fine." That is not enough. Authentication tells you who the user is. It does not automatically tell you what they should be able to do, what data they should see, what actions the agent can take, or what should happen if the model is tricked.

OWASP's LLM application guidance calls out prompt injection, sensitive information disclosure, insecure plugin design and excessive agency as core risks for LLM applications.8 NIST's AI Risk Management Framework is also useful here because it frames AI risk as something to govern, map, measure and manage across design, development, deployment and use.9

The Hidden Governance Object: Derived Data

One thing teams often miss is that AI systems create new data. Not just outputs. Derived data.

Embeddings, chunks, prompt histories, tool traces, evaluation sets, user feedback labels and generated drafts can all contain or reveal sensitive information. It is not enough to say, "the original document is in SharePoint." If the app copied chunks into a vector database, cached summaries in Postgres, wrote traces to an observability platform and stored feedback for evaluation, the governance surface has expanded.

That may still be worth it. But it needs to be intentional. In practice, the better architecture is often the smallest one that preserves the data boundary.

The Legal and Commercial Boundary Matters Too

There is one final data question that is easy to miss: are we actually allowed to use this tool, with this data, for this client, in this way?

That sounds like a legal question, but it quickly becomes a product and architecture question. A company may be comfortable using Copilot or Claude for internal drafting. It may be less comfortable using the same tool with client-confidential files, regulated data, employee data, source code, pricing models or acquisition documents. The issue is not just whether the vendor is secure. The issue is whether the use case fits the organisation's contracts, client commitments, data processing terms, retention rules and regulatory obligations.

With a vendor-hosted agent, the organisation needs to understand the platform terms: where data is processed, whether prompts and outputs are stored, whether data is used for model training, what subprocessors are involved, what admin controls exist, what audit logs are available, and whether the tool fits existing client obligations.

With a custom app, the organisation gets more control, but also more responsibility. It must decide where the app is hosted, which model provider is used, what data is sent to the model, whether outputs are stored, how logs are handled, who can access traces, and how the app complies with contractual or regulatory requirements.

This is especially important in consulting. One client may allow Microsoft 365 Copilot but not external model APIs. Another may allow anonymised analysis but not document upload. Another may require data to stay in a specific region. Another may prohibit using its materials to build reusable firm assets.

That means the build-versus-buy decision is not only technical. It is also about the safest operating boundary. If the organisation already has Microsoft 365 governance, retention, audit and client-approved terms, it may be safer to keep the workflow inside Copilot. If the use case needs stricter client isolation, custom review flows, explicit audit history or a dedicated data boundary, a small custom app may be safer, but only if it is properly owned.

The ICO's AI guidance is useful background here because it frames AI through UK data protection principles and risk assessment, including guidance and tooling for assessing risks to rights and freedoms.10 The EU AI Act is also relevant context for organisations operating in or serving the EU because it uses a risk-based framework, with stricter obligations for high-risk systems and transparency duties for some AI use cases.11 This article is not legal advice; it is a decision prompt for spotting when legal, data protection or commercial review belongs in the workflow.