An AI rollout program is the work of turning “our staff are already using AI” into a set of approved tools, a written policy, data that is classified before an assistant can read it, tenant controls that enforce the policy, a pilot group, and a review cadence. We run that program for Los Angeles businesses deploying Microsoft 365 Copilot, Claude, or both, in six stages over roughly eight to twelve weeks.
The reason it needs stages is that the risk is not the model. It is your file shares. Microsoft 365 Copilot answers a user’s question using content the user already has permission to open, which means a decade of overshared SharePoint sites becomes searchable by plain question rather than by knowing where to look. Microsoft describes the same problem and its controls in its own oversharing blueprint for Copilot deployments.
What the program covers
- Assessment. What AI tools are already in use, what data they can access, and where the permissions are wrong.
- Policy. A governance policy (AI Acceptable Use Policy or AI AUP) for the business and an acceptable use policy for employees. They are different documents.
- Data classification. A small label set is applied where it matters, before an assistant is turned on.
- Tenant controls. Data loss prevention, oversharing controls, and audit logging are configured in accordance with the policy.
- Pilot. A named group, a fixed period, and a decision at the end of it.
- Training and review. Role-based training at rollout, then a standing review of usage, exceptions, and new tools.
Stage 1: Assessment
We start by finding out what is already happening because, in every engagement so far, something has been. The assessment covers which AI tools staff have signed up for with a work email, which have been granted access to your Microsoft 365 or Google Workspace tenant through an OAuth consent, what your current sharing settings expose, and which SharePoint sites or shared drives hold sensitive content with permissions nobody has reviewed since they were created.
The output is a short written finding: the tool inventory, the data exposure list ranked by severity, and the specific items that must be fixed before a Copilot or Claude rollout, rather than after.
Stage 2: Policy
Two documents, because they answer different questions. The governance policy specifies who approves a new AI tool, what review it undergoes, which data classifications may be used with which tools, how usage is logged, and who owns the decision in the event of a dispute. The acceptable use policy is the employee-facing version: what you may paste into an assistant, what you may not, what you have to check before you act on an answer, and who to ask.
We write against the environment we found in stage 1 rather than from a template, and we align the structure with a recognized framework. Hence, the document survives a customer security questionnaire. The usual references are the NIST AI Risk Management Framework (NIST AI 100-1, published January 2023) and ISO/IEC 42001:2023 for organizations that need a certifiable management system.
If you want to read where we stand before engaging, our AI governance policy framework and our guide to an AI acceptable use policy for business are both published in full.
Stage 3: Data Classification
Classification schemes fail when they have too many labels. We start with three or four, mapped to how your business actually talks about its information, then apply them where the exposure is: client files, financials, HR records, and anything covered by a contractual confidentiality obligation.
In Microsoft 365, these are Purview sensitivity labels, and the practical benefit for an AI rollout is label inheritance. When Copilot generates a document from a labeled source, the generated item carries the label, so the protection follows the content into its new form. Encryption applied by a label also keeps Copilot entirely out of the most sensitive items, which is often the simplest control available.
Stage 4: Tenant Controls
This is the configuration work, where a governance policy becomes more than a document.
- Oversharing controls first. Restricted SharePoint Search limits Copilot to an approved list of sites while the permissions cleanup is underway, and data access governance reports identify the sites that need that cleanup. Microsoft documents both in its Restricted SharePoint Search guidance.
- Data loss prevention for AI interactions. Purview DLP has a policy location for Microsoft 365 Copilot and Copilot Chat that can stop prompts containing specific types of sensitive information from being processed and can exclude files with particular sensitivity labels from being used as grounding data. The behavior is described in Microsoft’s DLP for Copilot documentation.
- Endpoint DLP for third-party assistants. On Windows devices onboarded to Purview, endpoint policies can warn on or block pasting sensitive content into generative AI sites in a browser. This is how you manage the tools you have not approved without pretending nobody uses them.
- Posture management. Purview Data Security Posture Management for AI reports on which sensitive items are being referenced in assistant responses, which is the feedback loop that tells you whether the classification work landed.
- Audit and retention. Copilot interactions are auditable and discoverable through the same Microsoft 365 tooling as email and files. We turn that on and set retention deliberately rather than accepting the default.
- Identity. Conditional access and multi-factor authentication on the accounts that now have a much faster path to your whole document estate.
For Claude deployments the control surface is different: a business or enterprise plan, single sign-on, administrative control of which connectors and integrations are enabled, and clarity in the policy about what may be pasted rather than what may be indexed. We configure both stacks the same way in one respect: the tool follows the classification rather than the other way around.
Stage 5: Pilot
A pilot is a named group of 10 to 25 people, a fixed period of four to six weeks, a small number of use cases they were actually asked to try, and a decision at the end. We collect what worked, what produced output nobody trusted, what the audit logs show about which content was reached, and what the DLP policies caught. The output is a go, no-go, or fix-first recommendation with the reasons attached.
Running a pilot without a decision date is the most common way for an AI program to stall, so the date is set at the start.
Stage 6: Training and Ongoing Review
Training is role-based and short. Leadership gets the governance model and the exception process. Managers know how to review AI-assisted work. Everyone gets the acceptable use policy in plain language, with the three or four examples from your own business that matter most.
The review cadence is quarterly for usage, exceptions, and newly requested tools, and annually for the policy itself. New assistants appear faster than policies get rewritten, which is why the governance policy defines an approval path rather than a fixed list of approved products.
What this does not cover
We are not building or fine-tuning models, and we do not write the parts of an AI policy that are legal opinions. Where a rollout touches regulated data, we work alongside your counsel and your compliance obligations rather than replacing them. We help you meet the requirements; we do not issue the certification itself.
Contact Be Structured to schedule an AI governance assessment for your organization.
Be Structured Technology Group has supported Los Angeles businesses since 2007 from 500 S. Grand Avenue, and runs security operations, identity, and Microsoft 365 administration for the same clients we run AI governance for. That matters here because the controls in stage 4 are tenant configuration work rather than a separate product.
➤ Schedule Your Free IT Assessment
