AI Readiness and Legal Compliance: Practical Strategies for MSPs in the Age of Copilot

Freddy: Hello everyone, it is Freddy here from the inforcer product team. We are just on the hour, so we will give everyone a couple of minutes to join and then we will kick things off.

Hello everyone, it is Freddy here again. I mentioned that we would get started at two minutes past, so let’s begin. I am going to share my screen. Hopefully everyone can see it; if not, please let me know in the chat.

Welcome to today’s webinar, which is a joint session between inforcer and Cloud Contracts 365. Today is a webinar, but it is also intended to be a discussion, so please do get involved in the Q&A and chat. We are talking about two main areas: AI readiness and legal compliance. We will look at why these things are important, especially when considered together, and how you can think about practical strategies in the age of Microsoft Copilot.

By way of introduction, if I have not met you before, I am Freddy, Director of Product for AI initiatives at inforcer. I have worked in the industry for around 10 years, at inforcer and a number of other vendors in the MSP space, so I am MSP through and through. I am really excited to talk to you today about AI readiness.

Something I often joke about is that I get asked questions about what people should or should not do in the age of AI. I give my opinion, and then I have to say that I cannot really give legal advice because I am not a lawyer. Today, I am very pleased to be co-hosting with an actual lawyer. Kim, would you like to introduce yourself?

Kim: Thank you, Freddy. I have been a lawyer for over 20 years, 15 of which have been in the MSP and MSSP community, so I can safely say this is my bread and butter. I am also CEO and founder of Cloud Contracts 365.

Because my passion is legal work, it made sense to automate a lot of the contracts and reviews I was doing for MSPs into a legal AI platform, hence Cloud Contracts 365. Thank you, Freddy.

Freddy: Thank you, Kim. There are a few different topics we will go through today, and they boil down to four main areas. First, why AI and why now? There is so much changing in the industry every day: new technology, new opportunities and new risks. We will recap those trends.

Then we will do a deeper dive into AI readiness and how we see it as a mixture of opportunity and risk. We will look at how to uncover that opportunity and break the problem down into bite-sized chunks so you can take customers on an AI journey.

After that, we will look at legal and compliance risks. AI is powerful and becomes more powerful every day. Fundamentally, AI is almost a data problem and a governance problem, so legal and compliance considerations have to be at the forefront of everyone’s mind.

Most importantly, we want you to come away with practical steps. There is a lot of content about AI at a conceptual level, but we want you to leave with a concrete action plan: steps you can take today, tomorrow, this week and this month.

On that note, we will have a handout at the end, produced by our lovely marketing team. If you attend the whole webinar, we will send it to you afterwards. It covers key data points around the industry, AI adoption, shadow AI and key considerations for getting customers ready for AI, particularly Copilot readiness. It spans security, technical readiness, data governance, legal considerations and other areas.

Freddy: Let’s start with why AI and why now. Everyone is excited about AI, and that may be why you are on the webinar today. The market is evolving quickly. When I first joined the industry just over 10 years ago, a lot had already changed, and a lot more has happened since.

In the MSP industry, we have seen several paradigm shifts over the past decade and a half. We saw the move from break-fix to managed services. There used to be a clear distinction between managed services and managed security services. Now, if you are an MSP providing services on top of Microsoft 365, you are delivering security and cybersecurity as a service as part of that.

Then came the move to cloud first: the migration of on-premises workloads into the cloud, accelerated by drivers such as COVID-19. Microsoft then became an increasingly important tier-one provider, covering a huge span of services MSPs provide to customers, including collaboration and security.

Now it feels like we are on the precipice of another paradigm shift: AI readiness. Something I hear from almost every MSP I speak to is that they have never had so many customers excited about technology in such a short space of time. Customers do not always have an easy answer to what problem AI will solve, but they know it adds value and they are excited about it.

Freddy: There are risks and opportunities for MSPs, and we can look at them from several angles. On the opportunity side, I like to split it into two areas: using AI to drive your own internal efficiency, and leveraging AI as part of your managed service offering to drive value for customers.

For internal efficiency, AI can be a potential solution to process automation problems. You can automate administrative tasks, improve service delivery, improve onboarding workflows, improve your ability to support customers when something goes wrong, and reduce cost or do more with less.

For customer-facing opportunities, there are two main areas: project work and new recurring revenue. AI depends on a modern, cloud-first IT environment where data is available, governed correctly and secured properly. Taking a customer to the right level of readiness can become project work that you charge for, helping them achieve the outcomes they want from AI.

There are also recurring revenue opportunities. Providing Microsoft Copilot as a service is one example, but more advanced use cases include custom agents. Depending on how you look at it, developing custom agents can be similar to custom software development. That creates new recurring revenue opportunities based on the outcomes you deliver for customers.

There are also risks. The market is moving very quickly, and many businesses increasingly expect their service provider to provide AI as a service. If, as an MSP, you are not providing AI as part of your service offering, that may become a reason customers do not choose you.

Another risk is that contract duration in the sector continues to get shorter. Expectations are higher, and there is more pressure to quickly prove value. If you deliver AI, whether that is a Copilot project, building custom agents or something else, customers need to understand what outcomes they are receiving so they can decide to renew your services.

There are also opportunities to innovate in pricing. For example, you could develop custom agents, deploy them to multiple customers and use value-based pricing rather than simply pricing per application or per user.

Freddy: Let’s talk more about Copilot readiness. I often hear a version of this from MSPs: everyone is excited about AI, and customers call to say they are excited about Microsoft Copilot, but when you dig into it, they are not always sure what the business case is. They know there could be value, but they find it difficult to articulate how it benefits them, their department or the whole business. They also do not always know where to start.

The key point is that if you do not take action to help customers with AI, they will make that decision without you. This is shadow AI. Whether we like it or not, people are using AI more and more. There are many tools people can sign up for with a personal email account, and they may start putting business data into them even though the tools are unsanctioned.

Shadow AI will happen whether we like it or not. The stat on the slide says 75% of people are already using AI at work, which comes from a Microsoft report from last year. I suspect that today the figure is closer to 100%. For MSPs, that represents both risk and opportunity. If you are not providing AI as a service in some way, you are leaving money on the table. Customers will use AI from another vendor or buy it directly off the shelf, and they may not get the right ROI or have the right guardrails.

Freddy: With Microsoft 365 and Copilot, there are advantages to thinking about how Copilot benefits from everything you already do in a customer’s Microsoft 365 tenant. Copilot does not use a different security model. It uses the permissions, controls and configurations already in that tenant.

That includes conditional access with Entra, Defender, endpoint configurations, SharePoint, data governance and collaboration tools like Teams. Copilot is bound by those permissions and configurations, and it benefits from them for secure collaboration.

That dependency means it is very important to manage tenants effectively, especially across security, technical readiness and data governance. It also creates a fantastic opportunity. If you are already doing a good job of managing a tenant and making it more Copilot-ready out of the box, then when the customer comes to you with a business problem they think they can solve with Copilot, the project work required to take them to the next level is that much less.

Copilot is Microsoft-native and benefits from the controls you have already put in place. If you do not provide a secure, governed AI option, customers may start using less secure tools that do not respect their data governance obligations or drive the outcomes they are looking for.

Freddy: Copilot readiness brings several challenges. Traditional managed services involve high knowledge of IT infrastructure, but knowledge of the data estate and business processes can be lower. For example, understanding how SharePoint is actually used to process data, what workflows look like and what the business outcomes are becomes very important when you think about data governance and Copilot readiness.

SMBs want Copilot, but they do not always understand the complexities. There is often a lack of understanding around data governance, oversharing and the exposure of sensitive information. It is important to set expectations: yes, there may be a strong ROI, but some work needs to happen first.

Selling readiness can also be challenging because Copilot readiness is a journey. Ideally, you start with discovery and validation, understand use cases, explore pilots, test with certain departments or champions, gather feedback and adjust. That makes it a more complex sales process.

It is also a mixture of people, process and technology. Even if you had a tool that could assess Copilot readiness, you still need to engage the customer on process, controls, data governance and how people use Copilot. You also need to think about what happens after deployment: adoption, ROI, success, ongoing value and what comes next.

Copilot readiness is not just a technical problem. You need to think about what problems Copilot will solve. There is a spectrum of capabilities. On one side, Copilot is embedded in Microsoft 365 applications, such as Outlook, where it can help draft, summarise or improve an email.

Then there is standalone Copilot chat, which is similar to other large language model experiences but, in the paid version, can reference work information through Microsoft Graph. It is aware of documents and can support many use cases.

Then there are custom agents: agents that users can interact with to accomplish workflows, and autonomous agents that may take action behind the scenes. These capabilities can transform how different parts of a business get work done. For most customers, you will probably start with the more basic use cases embedded in Microsoft products, then take them on a journey where they see more value over time.

There are also several ways to build agents. Copilot Studio Lite enables non-technical end users to build their own agents and discover use cases, while Copilot Studio allows you, as an MSP, to build custom agents that can transform business processes.

Freddy: I like to break readiness into seven areas. First, use cases: what problems will Copilot solve, and what is the ROI? Some of this can come from Microsoft 365 adoption data, but it also has to come from discovery and validation with customers about business priorities and outcomes.

Second is data availability. Is the right data available? Is it in SharePoint, OneDrive, Teams or another Microsoft 365 location, or is it scattered across other places, including on-premises systems?

Third is security. Copilot provides powerful data analysis capabilities, so security has to be top of mind. Fourth is technical readiness: the customer needs to meet the requirements that allow them to get the full value from Copilot.

Fifth is data governance: making sure data is managed appropriately based on sensitivity. Sixth is rollout planning: once the customer is ready, who gets Copilot first and why? The first users need a good experience and should see value quickly. That is important to ensuring a successful AI and Copilot journey across the customer lifecycle.

On use cases and Microsoft 365 adoption, always start with the problems the customer wants to solve. Customers may bring ideas that could involve Copilot, but you should ask why the topic is coming up and how solving the problem ties back to a business outcome, such as growth, reduced churn, entering a new market or saving cost.

A big part of this is understanding business processes. One technique I recommend is user story mapping. For example, if a customer wants to make their sales team more efficient, map the sales process and identify where Copilot could help salespeople move faster, become more effective and drive growth. That helps you understand and articulate ROI as part of the business proposal.

Microsoft 365 adoption data can also tell a story. You can identify power users and people who may benefit most from Copilot, which helps build an overall ROI case.

Freddy: Security and technical prerequisites are probably bread and butter for many MSPs, but they become even more important in the age of AI. If a rogue actor gains access to something as powerful as Copilot, their ability to gather, extract and exfiltrate key information is significant. Conditional access and MFA for all users become even more important. Secure Score can also become part of the service you offer, helping customers reach an agreed target.

Technical prerequisites are not always required to start using Copilot, but they are important for getting the most value. Customers should be on the right update channel and have the right version of Microsoft 365 Apps installed so they can access Copilot functionality across Microsoft 365 applications and benefit from frequent feature updates.

Data also needs to be in Microsoft 365. Copilot is powered by data in Microsoft Graph, principally SharePoint, but also OneDrive and Teams. If the data is not there, Copilot cannot access it and cannot drive value from it.

Data governance is probably the biggest growth area for the industry. A lot of security and technical readiness is now modern managed service bread and butter, but data governance requires MSPs to move from providing infrastructure to developing a deeper understanding of how customers use that infrastructure.

That includes understanding where data is stored, which data is sensitive, how business processes use that data and what outcomes the customer is trying to achieve. SharePoint, OneDrive and Teams configurations and usage become very important. Microsoft Purview is also central, including information protection, data loss prevention, understanding whether those tools are used, identifying which information is sensitive, and implementing controls in a way that supports Copilot readiness without negatively impacting business operations.

Data lifecycle is also important. Copilot bases responses on the data it can access. If a business has years of old data sitting in SharePoint that is no longer relevant, that can undermine the quality of Copilot responses. Audit trails are also critical, especially for more advanced AI use cases where actions may be taken autonomously. You need audit trails so activity and changes can be tracked and monitored.

A good rollout plan is key to a successful AI customer lifecycle. You need to articulate who gets Copilot first and why, collect quick feedback, monitor adoption and engagement trends and think about how to prove ROI.

You should have use cases the customer wants to achieve and take users through them. Once Copilot is deployed to the first department or group of power users, you can start identifying upsell opportunities and expand Copilot across the organisation to create more value.

Freddy: When implementing controls for AI, there are several priority areas. First is identity and access management. In a cloud-first world, the perimeter is no longer really the endpoint or the network; it is the user. Conditional access and MFA reduce the risk of a malicious actor accessing Copilot.

Second is SharePoint, OneDrive and Teams. These workloads must be configured correctly for the organisation’s collaboration and external sharing needs. You need to understand how they are configured today and what should change for Copilot readiness.

Third is sensitive information and data loss prevention, where Microsoft Purview is the key tool. You need to help customers understand what their sensitive data is. Not all data is equally sensitive, so customers need to know which data must be protected and labelled. Data loss prevention policies can then be implemented. Certain sensitivity labels can also prevent information from being indexed by Copilot, reducing leakage risk for particularly sensitive content.

Fourth is shadow AI monitoring. If you do not provide AI, customers will use it anyway. Defender for Cloud products can help monitor which shadow AI tools people are using, which can inform the Copilot readiness conversation. You can show customers that users are already using AI, and position Copilot as the tool that integrates with Microsoft 365 and sits within the Microsoft security and governance envelope.

Finally, this is not set and forget. Business needs change across collaboration, security and data governance. You need visibility of configuration drift, and you should make AI readiness a regular talking point in QBRs so controls continue to fit business needs and outcomes.

A lot of what I have covered is about technology, but AI readiness is about people, process and technology. Getting a customer ready for Copilot may require significant changes to the environment. You may need to reconfigure SharePoint, start from scratch in some places, implement sensitivity labels for the first time or introduce data loss prevention for the first time.

That can have a non-trivial impact on how people work. They may be used to sharing data in a certain way, oversharing data or exposing sensitive information without realising it. Those technology changes affect processes, so you need to take the customer on that journey and help them understand how it ties back to the value they will get from using Copilot responsibly.

The people side is also essential. Training and enablement help users follow the process properly and make better use of Copilot once they are ready.

One last thought before I hand over to Kim: generative AI has been generally available for only a few years, and what it can already do is incredible. People sometimes become complacent about those capabilities, but the tools we have today will probably be the worst ones we ever use. In a month, another model will be available and we will be talking about how today’s tools were not very good. The pace of change is amazing. On that note, I’ll hand over to Kim to talk about the legal and compliance side.

Kim: Thank you. It is true that the AI we are using now is the worst we will ever experience, which is why I look at the risk side as well as the opportunity. I want to help safeguard you by thinking through the issues you need to consider when using AI, whether you are using it on behalf of a customer, using it internally or simply trying to understand the AI landscape. The legal landscape is changing every day.

I have three buckets that I would term as the high-risk issues of using AI: data privacy, intellectual property and confidentiality. Freddy talked about shadow AI, and it is important to remember that these risks are much more prevalent when shadow AI is involved because you are not even aware these tools are being used.

Data privacy is probably the most familiar because of GDPR. Intellectual property and confidentiality are less understood and often involve more mystery.

With intellectual property, the first question to ask when inputting information into AI is whether you have the right to put that data in. Is it your intellectual property or someone else’s? If you are aware of the answer and know how to handle it, that is one thing. If it is shadow AI and people are not aware of what they are using or inputting, there could be serious breaches of contract.

You need to educate your team so they understand potential leaks and risks. They need to ask whether intellectual property might arise and whether they have the right to use it. If it is someone else’s IP, you need to make sure you have the rights. Often you probably do not, so do not use it. You also need to look at the terms and conditions of the AI tool, because depending on the tool, outputs or inputs may be treated differently, including potentially becoming open source or being owned by that AI provider.

When you are putting your own intellectual property into AI, you may feel more in control, but you still need to understand what it means for your business. If your IP, such as business systems, processes or know-how, is being input and you do not own the right afterwards, what does that do to the valuation of your business? When you go to exit the business and someone asks about the intellectual property you own, you need to be sure you have ringfenced and protected it correctly.

Freddy and I discussed an example yesterday: creating an agent for clients. Where does the IP sit? The answer depends on what you are doing with the IP and how you are creating it.

If it is custom bespoke development, how much of it is truly bespoke to the client, and therefore something the client may want to own? How much is your general knowledge and know-how that you should ringfence so you can reuse and repeat it across industries and businesses? If you do not protect that position in your contracts, you could leak intellectual property you think you own. You may get to the exit of your business believing you own that IP, only for someone to say you do not. That can affect valuation.

If you are creating agents, think carefully about how you protect and safeguard your IP position.

The next area is breach of confidentiality. As with IP, whatever you input into AI, make sure you understand what the data is. Are you confident you know what confidential data is? If customers give you data, are you verifying whether it is confidential information? Are your employees aware of what they are handling?

As a lawyer, what concerns me is the risk you carry through potential breach of contract, reputational loss and related consequences. These are important for running your business effectively and creating AI opportunity in a safe environment.

On data privacy, you need to ask where data is being stored and processed in the AI tool, what subprocessors are involved and whether any consents are needed. Many AI tools involve profiling. People are also using AI for images and videos, so you need to ask whether you have the right consent to use someone’s image in an AI tool.

You also need to consider whether you have flowed this down into customer contracts and whether employee policies cover it. Data privacy is not just about where data is stored and processed; it is also about what you need to communicate to clients and employees about how AI is being used. Due diligence is key.

When looking at an AI tool, whether for your own business or on behalf of a customer, ask deeper questions across data privacy, IP and confidentiality, find routes to the answers, and communicate those answers through policies and contracts.

Kim: There are several consequences and further risks of AI use. Internal data breaches are one. In the early days of Copilot, there were stories of employees accessing financial information and salary information they should not have seen. You need to understand how data is shared, stored and secured both inside and outside the organisation.

There are also regulations to be aware of, depending on where you trade and who you do business with. GDPR is one example. HIPAA may apply if you are in the United States or working with an American company. The EU AI Act is relevant in Europe. In the UK, we have adopted AI principles, and the ICO website is a good place to track AI frameworks and updates. The UK appears to be moving towards heavier regulation, likely somewhere between the more relaxed US approach and the more restrictive EU approach.

Reputational damage is another risk. AI creates opportunity, but if your legal and compliance foundations are not in place, you can damage trust with employees and clients. Employee turnover can also become a concern if employees are worried about privacy, especially where employee information is used in AI tools, including by marketing departments.

Your privacy policies should be adjusted to reflect how AI is being used. For example, if you use AI bots on your website, your privacy policy should explain how data is stored, whether a third-party tool is involved and whether profiling takes place.

Customer loss is another risk. Breach of contract can lead not only to a terminated contract but also to a potential damages claim. If you have not done the due diligence correctly, you cannot always hide behind exclusions of liability. You need to be seen to be doing the right thing.

There are several documents you should review for legal and compliance responsibilities. First, review your privacy policy, usually hosted on your website. If you have not looked at it recently, it may already be out of date, especially if you use AI tools on your website. Seek legal advice if needed.

Website terms and conditions and cookie policies also need attention. If people use a chatbot on your website, they may input all kinds of information. You need appropriate protections, such as indemnities, to protect your business from misuse or abuse of your AI features. AI tools can convert leads well, but you still need to manage the legal position.

Client-facing contracts need AI clauses. Your standard contract terms should explain how you use AI and where IP sits if you are creating agent work. You can exclude some losses in your contract, but be careful how you write that. Please do not use ChatGPT to draft those clauses, because it may hallucinate and provide wording that presents itself as best practice but is not.

HR and internal policies are also important. Monitoring and training are key because shadow AI is prolific. How are you monitoring it? How are you helping customers think about it? What training can you put in place so they understand the risks and the importance of mitigation?

Consent is another area to review. If you use images or videos in AI tools, make sure you have consent. If a client’s face or photo is used in an AI tool, are they aware of how that tool may use the image going forward?

You should also maintain and evolve your DPIA. Pay attention to updates from the ICO. Have someone internally who likes process regularly check the ICO website so your business evolves with AI rules and can be seen to be compliant. Keep an eye on intellectual property and data protection rights, do due diligence, understand the criteria and consult when needed.

Freddy: Thank you, Kim. I will show the handout reference again, which we will send after this. If people want to take a screenshot of our contact details, both Kim and I are happy for people to reach out. If anyone has ideas or wants to talk about AI, feel free to get in touch. I will stop sharing so I can see the Q&A.

Audience: Will the deck be shared?

Freddy: Yes, the deck will be shared.

Audience: How can you make sure your agents are hardened, for example against AI prompt injection?

Freddy: That is a really good example. DSPM and Purview can definitely help, but it is also important to be clear that there is no cast-iron mitigation. From my side, a couple of key things matter. First, plan out what the agent can do so that if prompt injection happens, the negative consequences are mitigated.

If the agent can take actions, understand what those actions are and control them. Control people’s access to the agent so it is suitable and authenticated. Use tools like Purview on the monitoring and auditing side to reduce risk.

One of the main challenges with generative AI is that it is non-deterministic and can be socially engineered. The whole industry is tackling this, and the tooling is still catching up to a degree.

Audience: Do you have something we can use to help guide clients towards awareness of these issues, such as a list we can present to make sure they understand the areas of risk?

Kim: Yes. In the handout, we have a compliance checklist that you can use as a starting point. It is a complex area, so it is difficult to capture every clause or every thing that could go wrong, but the checklist is a good starter and a good conversation starter with clients. If something comes out of that conversation, feel free to reach out.

Audience: Any recommendations for how an MSP might assist or provide a DPIA for clients?

Kim: That is a great question because many people do not know what to write in a DPIA, and they may not know the technical details of how data is being used. Sit down with the client and go through their form. They should have a standard form. Identify where the knowledge gaps are, what tools they are using and where the data is being stored and used.

Audience: Will there be a best-practice DSPM for AI configuration on your Discord, or even as a feature in inforcer?

Freddy: Right now, we are building our first support for the Microsoft Purview stack, which is a portfolio in its own right. The first step will be supporting data loss prevention policies, which we are working on now, followed by sensitivity labels. We will also look at additional Purview capabilities moving forward because data governance is critical to successful AI adoption. I am always open to feedback on what we should prioritise because there is a lot within Purview.

Audience: With ISO 42001 in mind, how do you recommend approaching data processing in non-UK or non-EU countries? For example, if an MSP toolset introduces free AI into existing tools.

Kim: For any data processing in a non-UK or non-EU country, you need to understand where the data is being held and processed. It is difficult to answer fully without more detail, so I would ask for more information directly. Always understand where data is held and processed so you can understand which regulations may apply.

Audience: Are F4 milestones and tasks a good start on AI compliance?

Freddy: I am not personally acquainted with what F4 milestones are.

Kim: That does not ring a bell for me either.

Freddy: If you can follow up in the chat or reach out directly, we can discuss that further.

Audience: Any suggested documentation repositories for AI in CMMC environments?

Freddy: I am not fully up to speed with that acronym in this context, so please follow up with more detail. The challenge with compliance is that every country and organisation has its own compliance rules. In the UK, we have the ICO and DPIAs, which do not exist in every country in the same way.

Audience: The EU seems quite a bit ahead of the US regarding AI and data privacy. From a non-lawyer perspective, is that accurate?

Kim: Yes, that is accurate. The US is more relaxed with regulation in this area. It is also an interesting time for the UK because, as I said, the UK appears to be adopting a hybrid model between the restrictive EU AI Act approach and the more relaxed US approach. We already have AI principles and frameworks, so look at the ICO website and any relevant regulations you may touch. They are good at keeping people informed.

Audience: When is the AI readiness assessment coming out in inforcer?

Freddy: We have talked about that in a roadmap webinar. We are still working on it, and we are very excited about what the first iteration will include. We will look to provide an update very soon on timelines, but we are nearly there.

Audience: Will we get a recording of this?

Freddy: Yes, I believe we will send the recording, the PowerPoint deck, the transcript and the handout.

Audience: Since we attended this, do we get three free questions from Kim after the webinar?

Kim: Yes, you can always DM me. Anyone who wants advice can reach out to me on LinkedIn or by email. I am more than happy to help people on this journey. I have an AI business, so I have had to look at this not just from a legal point of view but from a business owner’s point of view as well.

Helping MSPs transition to MIPs, or managed intelligence providers, is a big passion of mine. I want to help them transform, so if anybody wants advice, feel free to come to me.

Freddy: Are there any more questions? If not, thank you all for giving up your valuable time to attend today. Kim, thank you very much for being a gracious co-host and for talking about the legal and compliance side, which I cannot talk to. Thank you everyone for the great questions and discussion as well.

This industry is changing quickly, and there are lots of unknowns. Everyone is still learning, so it is great to have the discussion and figure things out together. I will see you all at one of our next webinars. Goodbye.

Kim: Thank you, everyone. Goodbye.