Last week I made the case for taking your AI policy out of the boardroom and down into the boiler room. This week, let’s look at what actually goes in it (the policy, not the boiler room, I am not a Mechanical Engineer after all!).
At a minimum your policy should answer each of these.
What data can and can’t go into a model. Be specific. Building and site drawings, condition data, tenant and occupant information, security and access details, anything under an NDA. “Use good judgment” is not a policy.
What has to be reviewed by a human before it goes anywhere that matters. For most of you that isn’t a client deliverable, it’s a board package, a capital request, a council presentation, or a number someone is going to make a funding decision on. Everything you produce down in the boiler room eventually ends up back in the boardroom, and your name is on it when it gets there.
Whether AI-assisted work gets disclosed, and to whom.
Which tools are approved. What to do when someone wants to use one that isn’t. That second half is the part most policies forget, and it’s why people quietly use whatever they like.
What your vendors are doing with your data. This is the one I’d start with, and it’s the most uncomfortable. Your FCA consultant is putting your condition data somewhere. Your CMMS vendor shipped an AI feature last quarter and the release notes said very little about training. Your energy management platform, your BAS integrator, your space planning software, all of them are adding AI, and most of you have never asked what happens to your data when they do. You may also already have obligations in contracts you’ve signed. Go and read them before you write anything.
Whether AI output is a public record. If you’re in the public sector, this one deserves a conversation with your records and FOI people before you need the answer. If a director drafts a capital prioritization memo with AI assistance, is the prompt a record? Is the output? What gets produced when someone files a request? Most organizations have not worked this out yet, which means you get to find out the hard way or the planned way.
Whether AI can touch procurement. Can your team use it to help write a scope of work? To evaluate bids? To score proposals? Public procurement rules were written before any of this existed, and the silence is not permission. Get out ahead of it.
What your collective agreements say. If you run unionized trades, anything that touches scheduling, work assignment, productivity measurement or anything resembling performance monitoring can run straight into your collective agreement. Deploying something clever without checking first is a fast way to a grievance and a slow way to rebuild trust.
Who to ask when the policy doesn’t cover it. Name a person, not a department. Pick your own internal AI champion.
The one we went round and round on was how much extra review AI-assisted work should get. For us that meant client deliverables; for you it might be a board report or a capital submission. My position was that the standard doesn’t change, just as when someone writes something without AI, they have to re-read it, make sure they stand behind it, and then send it for peer review. The author is simply using a tool to help with the draft.
Where I got pushback, fairly, is that a polished AI draft doesn’t invite scrutiny the way a rough one does. It looks finished. That makes it easier to skim and harder to challenge. We landed on the same standard, but I’d be lying if I said that concern has gone away.
One area we’re still struggling with is whether and how staff can use our AI for non-work-related things. I personally don’t have a problem with our team asking for dinner recommendations or things to see when they’re travelling for work or otherwise, it’s fairly benign in terms of tokens, and therefore cost. But we’ve had to get more explicit as some people pushed those limits and started burning real volume on personal projects.
We haven’t found our sweet spot yet. I don’t want to ban personal use outright, because the people who experiment on their own time are the ones who get good at this fastest. But we haven’t found a clean line either. As with most things AI, we continue to iterate.
And for those of you who, like me, hate writing policies, here’s the good news. Get your AI to help you write it. Give it the parameters you want covered and let it do the heavy lifting.
One caution. The quality of what comes back depends entirely on the quality of what you feed in. Hand it a vague prompt and you’ll get a generic policy that reads like everyone else’s and that nobody follows, because it’s obviously boilerplate. Hand it your actual tools, your actual data types, your actual contract language, and it will get you most of the way there. Don’t think of your AI as a writer. Think of it as a co-author and editor wrapped into one. More on using AI for content creation in a future post.
Once you have your facilities policy written, keep an eye on the corporate policy as well, and make sure changes there get reflected in your document. Just because you align today doesn’t mean you will tomorrow.
None of this needs to be long. Ours isn’t. It needs to be specific, it needs to make sense to someone reading it on a phone in a boiler room, and it needs to exist before someone needs it.
I can’t believe I wrote one post on policies, let alone two. Thanks for sticking with me. It is not the most exciting part of the topic, but it is vitally important.
One key part of any policy is deciding which tools you want your team using. That’s where we’re going next week, where I’ll share our ever-evolving journey through the AI tools available to us.
