Before Rolling Out AI – Check your Data
In my efforts to understand the necessary planning for Copilot in M365, two recurring themes have covered the data we store in various M365 workloads.
- Check the access. I’m hearing many stories of folks who had access to documents they shouldn’t have access to where using Copilot exposed that fact. The example I think best explains this is an HR file SharePoint library or something that isn’t locked down properly. Most users have no idea they can access sensitive HR data and wouldn’t know where to look for it. (For example, it’s in a SharePoint library they’ve never been given a link to.) However, when they get Copilot and ask it for salary data, the AI tool has the same access they do and gives them the information. Essentially, Copilot is exposing data that is not secured correctly, so Microsoft recommends checking on that and automatically labeling sensitive data to cover yourself for those situations. (Essentially, label documents with sensitive data so that Copilot does not add them to the model, regardless of access.)
- The second one concerns the data that Copilot is using. On a recent podcast, Ben Schorr discussed the advantages of using Copilot with solid business data. I immediately thought of all the places with poor data—all those organizations that never get rid of anything in case they need it someday. (I’m looking at you, law firms, and others.) Should that data be in your Copilot model and used to respond to prompts? What happens when a prompt about policy or laws involving a topic elicits responses dating back to outdated information? How much has changed in the last 10-15 years? How much data do you have that is older than that?
Rolling out an AI model might turn into much more of an Information Governance exercise than you’ve bargained for. Maybe that’s a good thing, though. Maybe it’s time to get rid of all that junk, not just because of the junk itself but because it’ll make your AI rollout more successful.
Follow these topics: Tech
