Governance, Policy, and Risk | Blane Canada

Question 1

Do we need an AI policy, and when should we write it?

Accepted Answer

If more than one employee uses a computer at work, you have questions to face. Write the policy alongside your operational audit, not before it and not after an incident. Doing both at once means the guardrails reflect what is actually happening rather than what leadership assumes.

Everyone is racing to use AI. Very few are planning for it. You would expect AI policy to be a standing boardroom topic by now. Instead there is silence outside of IT circles.

Maybe you do not need a policy. But unless you think about it, you will not know until something goes wrong or clients start seeing you as out of step. Reviewing even a draft policy is a solid opening move if you have employees, especially younger employees. It will raise questions you have not considered but need to.

It is entirely appropriate for IT to drive the discussion, if you have an IT person on staff. Most small and mid-sized businesses do not. In that case you will learn about needing a policy only after you have a problem, and by then it may be too late.

The smart sequence is to establish your policy while you are doing your audit. That overlap is what most companies miss. Systems, performance, and governance examined in a single discovery loop means the guardrails are written against what is actually happening rather than against what someone imagined. Strategy meets reality. Risk meets readiness. If you have not set your AI policy yet, maybe do not launch another chatbot this week.

Question 2

How do we protect confidential company and client information when using AI?

Accepted Answer

Decide which platforms are approved for sensitive work, name the categories of information that may never go into an unapproved tool, and teach people the difference. Technical controls help. They do not replace the moment when someone has to recognize that the document in front of them contains client information.

The easiest security mistake in this category is also one of the easiest to prevent, which is putting sensitive information into the wrong system.

Start with the distinction most staff have never had explained to them. A personal consumer account and a properly configured enterprise environment are not interchangeable, even when the interface looks identical. In many enterprise setups your data is protected at an organizational level. In a personal account it may be used to improve the model unless someone turned that setting off, and most people do not know the setting exists. When we run training, locking down privacy settings is in the first session rather than an appendix, precisely because the gap is that common.

Then name the categories in language your people will recognize. Client information. Personnel and compensation data. Anything under a confidentiality agreement. Financial detail that is not public. Give examples from your actual work, because abstract categories do not survive a deadline.

The exposure worth understanding is what happens when this goes unmanaged. Work product ends up sitting in a vendor's database that nobody at your company can inventory. An employee who cannot use a tool at work uses it at home, and now the material is fully outside your supervision. An analysis gets shared with a friend who offered to run it through their own tool.

The objective is not preventing people from using AI. It is making sure they can see the line.

Question 3

Can I trust what AI tells me?

Accepted Answer

Trust, but validate. AI can produce flawed reasoning wrapped in confident, persuasive language, which is harder to catch than an obvious error. Every AI-generated insight needs a second look: does this make sense, can I verify it, and could I defend it to a client or a board?

We have been here before. People used to back up an argument by citing the web, with the implicit logic that if it was online it must be true. We learned the hard way that not everything online is accurate.

AI is bringing us the second version of that story, faster and shinier. It can draft proposals, summarize reports, and evaluate ideas. It can also generate flawed reasoning in language so fluent that experienced professionals accept it.

Research out of Harvard Business School found that when humans and AI work together they can identify strong ideas more efficiently than either could alone, but that people sometimes surrender their own judgment and defer to the system even when it is wrong. The systems produce persuasive-sounding justifications that sway human judgment even when the underlying reasoning is weak. As the researcher put it, you really need humans synthesizing and validating, and you have to know when to question an AI-generated evaluation.

There is a related caution about AI-driven search. Research from the Tow Center for Digital Journalism at Columbia, which tested eight major models, documented confident presentations of incorrect information, misleading attribution to syndicated content, and inconsistent retrieval, with the tested tools answering a majority of queries incorrectly and the best performer still getting a substantial share wrong. Citation was a particular weakness: links to the wrong article, links to a site's homepage, or no citation at all. If a tool gives you information with no traceable source, and verifying it means going back to a search engine anyway, its value for research is limited.

If we are not careful, we will start trusting AI the way some people blindly trusted the internet, and reputations will suffer for it.

Question 4

What should an AI use policy actually cover?

Accepted Answer

Three questions answer most of it. Who is accountable for what the AI produces? What data is off limits? What is acceptable, what is not, and what is enforceable? Add a clear position on which outputs require human review before they leave the building.

Your policy is not just legal language. It tells your team what is acceptable and what matters, which makes it a culture document as much as a compliance one.

Start with those three accountability questions, then extend into the areas where people actually make judgment calls. Where must AI output be reviewed by a human before release? How do you handle inaccurate or biased output when it occurs? What are your obligations around customer data and regulatory compliance? When and how do you disclose AI involvement in customer-facing work? Who owns governance overall?

Culture shows up in micro-decisions. Should I use an AI tool for this client email? What is okay to automate? Where is the line? Your people are answering those questions right now, one at a time, with no guidance. Clarity drives behavior. Guardrails are not red tape. They are a compass.

The best use of a draft policy is not enforcement. It is conversation. Bring your team together, walk through it, and find out what they are actually doing and thinking. If you have younger or more adventurous employees, you may be surprised. Bring it into the open and keep the dialogue going.

Question 5

Who is responsible when AI produces a wrong answer?

Accepted Answer

A person, always. AI can draft, analyze, and recommend, but accountability cannot be handed to a model. Define in advance who reviews consequential output, who approves action, and who owns the result. If nobody can answer that question, the problem is not the model. Your governance is incomplete.

"The AI made a mistake" is not an accountability structure. It is a description of an outcome nobody had assigned.

The level of review should scale with what happens if the output is wrong. An internal draft that a person is going to rewrite anyway needs very little supervision. A commitment to a customer, a legal communication, a personnel decision, a financial recommendation, or anything touching safety needs a named human between the output and the action. Most organizations have never drawn that line, which means it gets drawn under pressure by whoever is closest when something goes wrong.

Three questions settle most of it. Who owns this workflow? Where in it does a person have to approve before anything leaves the building? What is supposed to happen when the output looks questionable, and does that person have the authority to stop it?

That last one matters more than it sounds. Plenty of organizations have someone nominally reviewing output who has no practical ability to halt the process, which is not oversight. It is a signature.

If your guardrails are not enforced, they are not guardrails. They are guidelines. And if no one owns the output, the policy is broken regardless of how well it reads.

Question 6

What happens when employees use their own AI tools for work?

Accepted Answer

You lose control of the work product and sometimes the capability itself. An employee who trains a personal tool to do their job extremely well has built something valuable that the company does not own, cannot supervise, and cannot keep when they leave.

I watched this play out with a department head who was a sophisticated user rather than a technical professional. She learned to make her own tools respond to her needs at a high level, and the results were excellent.

Later, when the company got around to thinking about an AI policy, they wanted everyone on company tools. Her response was reasonable from where she sat: mine is trained, it does exactly the job I need, and I am not going to have a group of beginners feeding it material that degrades my workspace. Not in your interest or mine.

That is the problem in one exchange. Beyond the immediate friction with that department head, consider what happens if she leaves. You do not control that trained tool. The business loses the time and money that went into developing a specialized capability, and it walks out the door with her.

There is an enforcement version of the same problem. If people cannot use their preferred tool at work, some will use it at home. Who is the wiser? At that point your work product is no longer under your supervision at all.

It is worth separating two pieces of advice that get blurred together. Start using it and figure it out is excellent guidance for a person and risky guidance for a company. When you personally test a tool on your own work, the worst outcome is a wasted hour. When forty people each pick their own and train it on company information, the outcomes compound.

The answer is not prohibition, which pushes the activity out of sight, and it is not silence, which produces sprawl. It is a defined safe zone. People know which platforms are acceptable, what information is prohibited, and when a person has to review something before it leaves. Then give them somewhere to report what worked: what problem they solved, which tool they used, what it saved. That turns private experimentation into something the company learns from, rather than dozens of invisible personal workflows.

The exposures compound: loss of proprietary information, insecure storage, and conversations outside the company. An employee working on performance data mentions it to a friend who offers to run an analysis, and a file moves. Is that acceptable to you? The point is not that your people are careless. It is that nobody told them where the line was.

Question 7

One department bought and launched an AI tool without telling anyone. How do we prevent that?

Accepted Answer

Create one function accountable for knowing what AI tools are in use, what they do, and what the organization has learned from them. This is not an accounting job and it is probably not an IT job. It requires cross-functional authority and strategic judgment.

A marketing department launched an AI-powered intranet company-wide with no advance notice. Nobody asked IT. Nobody checked what else was being evaluated. It landed like a surprise package on everyone's desk, and then they had to configure it.

That is not an AI problem. It is a governance problem, and most executive teams do not see it until it bites them. When we run an assessment across goals, operations, team capabilities, and governance, governance is consistently the dimension that surprises people.

The fix for both this problem and the spiraling costs that come with it is a central AI intelligence function: one place accountable for knowing what is in use, what it is doing, and what has been learned.

It is not accounting's job. Tracking invoices is not the same as managing a strategic portfolio. It is probably not IT's job either, because IT manages infrastructure while governance of AI decisions requires cross-functional authority and business judgment.

Checks and balances are not bureaucracy. They are how you keep a modest experiment from quietly becoming an expensive problem, and the gap between those two numbers is usually an order of magnitude.

Question 8

Is AI governance going to slow us down?

Accepted Answer

The opposite. Without guardrails, innovation becomes liability and adoption stalls the first time something goes wrong. Governance is what lets you scale AI safely and confidently. Confidence drives adoption, and adoption is where the return actually comes from.

Too many executives treat policy as paperwork. Here is what I tell clients: governance is not a blocker. It is an enabler.

AI can move fast, but trust has to move faster. When nobody knows who is accountable for an output, what data is off limits, or where the line is, two things happen at once. Cautious employees do less than they safely could, and confident employees do more than they safely should. Both of those cost you.

A clear policy removes the ambiguity that produces both behaviors. It tells the cautious person what is permitted so they will actually use the tool, and it tells the confident person where to stop. That is what makes speed possible rather than reckless.

Good governance multiplies speed. It does not slow it down. And if your guardrails are not enforced, they are not guardrails. They are guidelines.

Question 9

What controls stop our people from acting on wrong AI output?

Accepted Answer

Four things. A designated human oversight loop for key outputs. Training that teaches people to spot polished nonsense. A culture where questioning the tool is normal. And a validation habit built into the process rather than left to individual discretion.

Create a human oversight loop. Designate who reviews and fact-checks key AI outputs before they go anywhere. Make it part of the process, a requirement rather than a courtesy. The moment it is optional, it stops happening under deadline.

Train teams to spot polished nonsense. Run regular exercises mixing sound and flawed AI-generated content and see who can tell the difference. Make it a real exercise with real stakes. The skill of recognizing confident wrongness is learnable, and almost nobody has been taught it.

Build a culture where questioning the tool is normal. Normalize saying "let us double-check that." Reward curiosity rather than blind efficiency. If the fastest path through a task is to accept the first output, that is what people will do.

Validate every insight before you act on it. Three questions: Does this actually make sense? Can I verify it? Could I defend it to a client or a boss?

The future of work is not AI-powered. It is human judgment enhanced by good tools and made stronger by the willingness to say, wait a second, is that really true?

Question 10

We are too small to have policies on anything. Why should AI be different?

Accepted Answer

Because the playing field is not formed yet. With established software, standardization from a handful of major vendors made informal management workable. Nothing like that exists on the AI frontier. New tools appear daily, employees pick their own, and the exposure compounds quietly.

As the owner of a small software company, I was not always on top of the tools my team used. If they needed something, they got it. There was a team lead who set the tone for how things were done, we were standardized on one vendor's ecosystem, and that set useful parameters. I had a great team that cared and worked hard. Everything worked.

I could not take that hands-off approach today with AI.

The playing field is not fully formed. Different team members have different ideas, and new tools drop daily. Some employees want to try everything to find what is best this month, then move on to the next one, leaving money behind in subscriptions and prepaid tokens. Nobody else may even know the company has access to that tool. This quickly produces duplicate subscriptions and work product stranded and exposed in some vendor's database.

The greatest gift Apple, Google, and Microsoft gave business owners was standardization. Nothing like that exists yet in AI. It will come as the front-runners consolidate. Until then, an owner has to be more vigilant than the size of the company would normally require.

You do not need a sophisticated solution. A shared list of what tools exist, what they do, and which ones the company actually subscribes to will handle most of it. You cannot apply common sense to exposure you are not thinking about.

Question 11

We wrote an AI policy and nobody follows it. What are we missing?

Accepted Answer

Training. Writing the policy is step one. If your team cannot answer what they can use a tool for, where client data goes, and who is responsible when it gets something wrong, you do not have guardrails. You have a document.

Policy and training go together, and the order matters less than the fact that neither works alone.

Consider a typical, well-intentioned AI memo. Do not input confidential client information into non-enterprise tools. Turn off model training so your inputs are not used to improve the AI. Thoughtful exploration is fine for general productivity work. Every word of that is correct.

And every word of it assumes three things that are usually not true for a meaningful share of staff. That the people who most need to hear it understand what those terms mean. That they know where to find that setting inside the tool. That they can reliably distinguish general productivity use from client-sensitive work in the moment, while under deadline pressure.

Those are three large assumptions. In most professional services firms, at least one of them is wrong for a significant part of the staff.

This is what happens when leadership discovers activity and drops in governance without an assessment. The guardrails go up before anyone knows what is being guarded, who is doing what, or where the real exposure is.

Policy needs teeth, and training is the bite.

Question 12

Is sending an AI usage memo to staff enough?

Accepted Answer

No. A memo assumes a level of understanding that usually does not exist yet, and it assumes leadership already knows what is happening. Firms that handle this well start with a diagnostic of what is in use, what the capability range looks like, and where the risk sits. Then they write guidelines that match reality.

A memo that says "more to come" buys time. It does not buy confidence.

The right concerns in the wrong order produce a specific failure. Staff read the memo, most of them cannot fully act on it, the compliant ones become slightly more cautious, the ones already deep in these tools continue exactly as before, and leadership now believes the issue has been addressed. That last part is the expensive one, because it closes the topic.

An honest baseline surfaces four things a memo cannot. What tools are actually in use across the company. What the real capability range looks like, which typically spans from people who have never opened one to people building applications. What is being considered by people who have not raised it yet. And what the governance exposure looks like in practice rather than in policy.

Those are different pictures and they rarely match. Guidelines built on the real one are enforceable. Guidelines built on the assumed one are decoration.

Question 13

Does having several AI platforms across the company create risk?

Accepted Answer

Yes, and the risk is mostly about security and visibility rather than cost. Every additional AI-enabled system extends your attack surface and holds a partial, differently structured view of your operation. The question of whether to standardize is separate. This is about what the sprawl exposes while you decide.

This is happening in a great many enterprises right now, largely because every major software provider is racing to add AI to what you already own. Your platforms are acquiring AI whether or not you chose it.

One technology leader described the effect with a useful analogy: ask six blind men to touch an elephant and describe it, and you get six different answers. That is what happens when six systems each hold a partial, differently structured view of your operation and each of them can now act on it.

The security dimension is not theoretical. More surfaces mean more exposure at a moment when attacks themselves are getting more capable. And there is a quiet irony in how most companies are managing it: the providers whose systems create much of the risk are frequently the same ones being relied on to secure it, because their security features are already integrated and therefore easiest to adopt.

The name for this is tool sprawl, and it is worth defining because it is a governance problem rather than a technology problem. Marketing picks one platform. Finance picks another. Individuals subscribe to several more. Your existing software quietly adds its own AI features. Before long nobody has a complete view. Beyond cost and security exposure, it recreates an old operational problem: your people become the integration layer again, moving between systems by hand to finish one piece of work. A periodic inventory answers most of it. What tools exist, what problem does each solve, what data does each reach, and where do they overlap?

The practical answer for most mid-sized companies is not to build sophisticated orchestration, which is an engineering investment few can justify. It is to know what you have, to require that anything touching customer or employee data be reviewed before it goes live rather than after, and to make sure one person can produce an accurate list of what is running on request. That last item sounds trivial until you ask for it.

Question 14

How should oversight tighten as AI systems gain more capability?

Accepted Answer

In proportion to what the system can do without asking. A tool that drafts text carries different exposure than one that changes records, reaches customers, or starts a workflow. As authority grows, permissions narrow, logging increases, approval points appear, and you need a way to stop the thing quickly.

Governance written once at the start of AI adoption will not survive contact with what these systems become. It is an operating discipline rather than a document.

The threshold that changes everything is the move from generating information to taking action. As long as a person has to read the output and decide what to do with it, that person is the control. Once the system can write to a database, send a message, or trigger a process on its own, the control has to be built rather than assumed.

At that point the questions get concrete. What can this system reach? What can it change, as opposed to only read? Which actions require a person to approve before they happen? What activity is logged, and does anyone actually look at the log? How would you notice an anomaly before a customer did?

And then the one that gets skipped. One security professional put it plainly: you need a big red button, and without that, do not put anything into an operational setting. A hard stop has been recommended as a standard part of the security framework for these systems, and it is not a dramatic precaution. Manufacturing equipment has emergency procedures. Financial systems have transaction controls. An automated workflow that can act on its own deserves the same thinking.

Autonomy without the ability to interrupt it is risk you did not need to take.

Question 15

What quality problems should we expect from AI-generated software and solutions?

Accepted Answer

Expect discipline to be missing. After reviewing a lot of AI-generated builds, the enthusiasm is there and the testing is not. Inconsistent labels, no attention to timing or refresh behavior, key functions buried, and sample data treated as adequate for testing.

We are repeating mistakes the software industry learned to avoid decades ago. Developers are excited about what AI can do and rush to create builds and add features. That is the good news. The discipline is not baked in. Testing, quality control, and simple usability appear to be afterthoughts or skipped entirely.

This is a governance question as much as a technical one, because the person who has to live with a poor-quality system is rarely the person who approved it. The warning signs are consistent. Different labels for the same thing in different places. No consideration of flow timing or page refreshes. Priority elements buried three levels down. Delivering high volume with a low match to the actual criteria. Assuming AI-generated sample data is adequate for testing. One-size-fits-all assumptions that ignore how different the users actually are.

The result is solutions that technically function and miss the mark. The minimum bar should not be "gets a reasonable answer." It should be "delivers real value to the people who have to use it."

Quality control is not glamorous. It is what turns a clever technical solution into something a business can rely on.

Question 16

What are the biggest risks of moving too fast on AI?

Accepted Answer

Solving the wrong problem, automating a broken process, exposing information before governance exists, acting on output nobody verified, accumulating disconnected tools, and discovering late that nobody owns the outcome. The risk is not speed. It is speed without diagnosis, which produces every one of those.

The pressure is real and it is not irrational. Competitors are experimenting, the capability is improving quickly, and a board is asking. The danger is confusing moving fast with skipping steps.

A rushed project usually goes wrong in a predictable order. It starts before the business objective is defined precisely enough to measure. Data problems surface after development is underway, when they are expensive rather than cheap. Employees receive a system they were never asked about and quietly route around it. Security questions get raised after sensitive information is already flowing through the tool. Meanwhile other departments have adopted their own products independently and leadership has lost visibility over what is actually running.

What makes this worse now than in previous technology cycles is the compression. Speed without diagnosis produces the same failures that have stalled technology projects for decades, just on a shorter timeline. In my experience, what used to take eighteen months to go wrong now takes closer to three, which means there is less time to notice and correct.

The answer is not moving slowly. It is moving deliberately, which is a different thing. A focused assessment, a narrow pilot, one named owner, and basic guardrails will improve decision quality substantially without turning adoption into a year-long planning exercise.

Move quickly once you know what you are moving toward.