The Workshop Diary is an ongoing series about how tools really come to be, in my own and clients’ projects, from idea through error to iteration. This is part 3. Earlier: part 1 (local AI) and part 2 (buying power).

Parts 1 and 2 started from the assumption that the data is on your own machine and you decide whether it leaves. But for a vast share of organisations the data already lives in the cloud, more precisely, in Microsoft 365. Does this overturn the whole “keep the data at home” idea? No. It changes the question entirely.

When the knowledge lives in a managed cloud, the question is no longer only “where is the data physically”. It is three questions: who controls access to it, where it rests under the contract, and whether you can reach your own data programmatically. Let’s go through the four pieces that change the picture, and one principle that ties them together.

SharePoint: a cloud whose location you can choose

SharePoint and OneDrive are the document layer for many organisations, the same document chaos as in part 1, but in the cloud. The decisive difference from consumer cloud is that you can define the location and the governance. Microsoft’s EU Data Boundary keeps the data inside the EU, and it is under your tenant’s control, under contract. It is not “somebody’s cloud”. It is your space in a managed cloud.

SharePoint also brings governance tools that scattered files do not have: version history, retention and deletion policies, access management and traceability of who did what. These are exactly the processes whose absence created the document chaos of part 1. Still, it is honest to say: this is not the same as your own machine. You trust Microsoft and the contract. But the trust is explicit, the location is known and access can be controlled precisely, a vast difference from files lying around as email attachments and on personal cloud accounts.

The Graph API: your own data within programmatic reach

Microsoft Graph is the interface through which you reach your own data programmatically, files, mail, calendar, users, groups, all behind one interface. This is where part 1’s RAG returns to the picture: a RAG system can be fed straight from SharePoint via Graph, with the right permissions, staying the whole time inside the tenant’s governance.

Here permission management is everything. Graph’s permissions split roughly into application permissions (the app acts on its own) and delegated permissions (the app acts with the signed-in user’s rights). The principle of least privilege applies here literally: the RAG connector is given permission to read only what it actually needs, not the whole organisation’s data if one workspace is enough. That way your own AI layer is built on top of the data without removing the data from the managed environment.

Shared responsibility: what is Microsoft’s, what is yours

The cloud’s most important, and most often misunderstood, principle is the shared-responsibility model. The provider is responsible for the security of the infrastructure: data centres, hardware, platform upkeep. You are responsible for what happens on top of the platform: who reaches the data, how rights are shared, how accounts are secured and how the service is configured.

This matters because the vast majority of cloud leaks do not come from the provider failing, but from the customer side being left half-done, a misassigned right, a share left open, an unprotected account. Moving to the cloud does not remove security work. It shifts its centre of gravity from hardware and the network to identity and configuration.

When the data is in the cloud, the firewall is no longer at the edge of the network. It is in identity, in who reaches what, and on what conditions.

Intune and device management: the boundary moves from the device to identity

Traditionally the security boundary was the office network: inside the network you were trusted, outside you were not. Remote work and the cloud broke this for good. Device management, such as Intune, moves the boundary to the device and to identity: reaching the data requires a managed, compliant device and an authenticated identity, not a particular network. Conditional access means, in practice, rules like “this data can be reached only from a managed device with up-to-date protection”.

This also changes where a local AI machine fits. Part 1’s local RAG machine on a managed, encrypted device behind conditional access is an entirely different thing from the same model on an unmanaged home computer. Data sovereignty turns out to be not just “local or cloud”. It is also “managed or unmanaged”. A local solution on an unmanaged device can be worse than a cloud on a managed one.

Identity management is the new firewall

At the heart of all this is identity and account management. In the cloud world, whoever controls identities controls the data. The principle of least privilege, multi-factor authentication (MFA) and conditional access are the controls that actually decide, not the location of the data centre as such. Admin rights are kept few, elevated rights are granted only when needed and for a limited time, and there is a separately designed emergency route for a crisis.

This is also where many stumble: a fine cloud is bought but the accounts are left half-finished, shared credentials, no MFA, too many admins, old accounts that should have been closed. Then the data is exactly as safe as the weakest credential. An expensive cloud does not fix loose account management; it just moves the looseness to a new place.

What about smaller companies?

All of the above assumed an organisation that has bought a managed identity and device stack. A large share of SMEs have not. They run a jumble: Google here, Outlook there, Proton somewhere, personal devices, no device management, no single sign-on. For them this part offers no direct recipe, a managed stack is a big investment in both money and know-how.

But for them there is a lighter path of their own, building the necessary pieces yourself with a little code instead of buying a ready-made stack all at once. That is the subject of the series’ final part.

Part 4: when security was never bought, how an SME builds its own solutions in Python across Google, Outlook and Proton.