The answer, more often than it should be, is the owner. Or the office manager. Or the person who set the whole thing up six years ago and never thought about it again. Their everyday email (the one they use to send quotes, open PDFs from strangers, click links from vendors, sign into apps on their phone) is also the account that can do anything inside the environment. Reset anyone’s password. Read anyone’s mail. Turn off security controls. Wipe a laptop. Hand the same keys to someone else.

That’s the tell. When the daily-use account and the top-level admin account are the same account, nobody has been thinking about how bad a bad day could get.

Picture it this way. If this account gets compromised (phished, password reused on some breached site), how far does the damage reach? When it’s the top-level admin, the answer is “everywhere.” Email, files, identities, backups, settings, the whole environment. One bad click and an attacker doesn’t just get into one mailbox. They own the place.

There are two fixes, and most organizations skip both. They’re not exotic. They’re not expensive. Microsoft has recommended them for years. The honest reason they get skipped is that they take real hours to set up, and someone has to make the case for spending those hours when nothing is currently on fire. That’s a hard sell internally, and it’s a hard sell to a client when the invoice shows up. Often there are just too many other fires to put out, and this isn’t one of them yet. So it sits.

The first fix: a separate admin account you only sign into when you need it. Your everyday account, the one used for email and Teams and the apps on your phone, has no admin rights at all. When you need to do something administrative, you sign into a different account that exists only for that. Different username, different password, different MFA. The account exposed to the internet all day, clicking links and opening attachments, is not the account that can blow up your environment. If it gets compromised, the damage stops at one person.

The second fix is giving people only the access they actually need. Stop handing out top-level admin as the default. Someone who resets passwords for the help desk doesn’t need it. Someone who manages email groups doesn’t need it. Someone who handles new hires and departures doesn’t need it. Microsoft 365 has more specific roles for all of these. They give people what they need to do their job and nothing more.

This one gets skipped because it takes extra thought and care. Figuring out who needs to do what, and matching that to the right role, is a small project. It’s easier to just make everyone a top-level admin and move on. That’s how it quietly becomes the norm. Three people need to do “some admin stuff,” three people get full keys, and nobody ever revisits it. If one of those accounts gets compromised, or one of those people leaves on bad terms, the damage is the same as if the owner’s account got hit.

This is one of the quieter reasons IT support for a small business looks different than people expect. The flashy work is the new laptop, the migration, the helpdesk ticket closed in twenty minutes. The work that actually saves the company is the boring inventory of who has what, and the patience to keep it tidy over time. Whether that work happens inside the building or through outsourced IT, somebody has to own it. If nobody owns it, it doesn’t happen.

This isn’t about distrust. It’s about containment. The fewer rights any one account has, the smaller the damage when something goes wrong. And something will go wrong eventually. That’s the whole reason we’re talking about this.

A worthwhile thing to do this week: open your Microsoft 365 admin center, go to Roles, and look at who has Global Administrator assigned. If the list includes the everyday email accounts of people who use those mailboxes all day, you’ve found a real problem. In a small business, more than two or three names is usually a flag too. In a larger org, the right number scales up, but the principle holds: it should be a deliberate list, not an accidental one.

Then have the conversation with your team or your managed IT services provider. Not “are we secure.” That question is too big to answer usefully. Ask the specific one: “Who has what admin permissions in our environment, why do they have it, and what would happen if any one of those accounts got phished tomorrow?”

The difference shows up in how the work moves. When you delegate a task, you stay in the loop. You’re approving, nudging, checking in, holding the outcome in your head. When you delegate a function, someone else owns the outcome and moves it forward whether you’re watching or not.

Picture a strong finance lead who owns the function. Budgets get built, forecasts get updated, the audit gets scheduled, cash gets watched. None of it waits on you to ask. Now picture a bookkeeper you have to poke every month to send the close report. Same domain, completely different relationship.

The same pattern shows up in marketing, HR, facilities, and IT.

This is where the conversation about managed IT services tends to go sideways. Leaders evaluate providers on task-level questions: how fast does the helpdesk respond, how quickly do tickets close, how smoothly do new users get set up. Those questions matter. They just aren’t function-level questions. They’re dispatching questions wearing a managed-services costume.

A function-level question sounds different. Does the proactive work that nobody is going to nag anyone about actually happen?

Things like: the annual IT plan that ties technology decisions to where the organization is actually going. The IT budget that doesn’t surprise the board in March. The lifecycle roadmap that says which devices and systems are aging out and when. The cybersecurity audit that gets scheduled because it’s time, not because something broke. The risk review that surfaces what’s quietly drifting. The governance conversation about Microsoft 365, or Copilot, or AI tools that staff are already using whether you’ve sanctioned it or not.

Nobody is going to file a ticket for any of that. It only happens if someone owns it.

A quick example of what function-level ownership actually looks like in practice. We worked with an engineering firm where the brief wasn’t “fix this ticket” or “stand up this server.” It was: build a phased IT roadmap, reduce reliance on aging in-house servers, get SOLIDWORKS workloads into Azure, and set the team up for flexible remote work with centralized cloud storage. That’s a function-level engagement. The output wasn’t a faster helpdesk. The output was a hybrid environment with less complexity, a scalable cost model that grows with the team instead of front-loading capital expense, and the security posture that comes with running inside Microsoft 365. None of that work was going to surface from a ticket queue. Someone had to be thinking about it on the firm’s behalf.

Here’s a test worth running: if you went on a three-month sabbatical tomorrow, would your IT function still move forward? Would the planning happen? Would the renewal conversations get scheduled? Would the risks get surfaced? Would you come back to find decisions waiting for you, or work already moving?

If the honest answer is that tickets would keep closing fast enough that nobody complains, but nothing forward-looking would happen, you haven’t handed off a function. You’ve outsourced a queue. That’s a real service. It just isn’t the same thing.

This is also the question to sit with before deciding whether to outsource IT or build it in-house. The choice isn’t really internal vs. external. It’s queue vs. function. A small in-house team can own the function beautifully if that’s what you’ve asked them to own. An outsourced IT partner can own it too. Either one can also drift into pure dispatch mode if nobody is clear about the brief.

The distinction matters more than it used to, because identity, security, data governance, productivity tooling, vendor sprawl, and employee experience are all being re-examined at once. The organizations that handle this well are the ones where someone is actively thinking about all of that on their behalf, not just reacting when something breaks.

And here’s the part worth sitting with: this isn’t a vendor problem first. It’s a leadership problem first. If you’ve never asked your IT partner (or your internal team) to own the function, they’ve probably defaulted to owning the queue. That’s a rational response to how they’ve been measured. The fix isn’t necessarily a new provider. The fix is changing the conversation about what you’re asking them to own.

A few questions that get at this directly:

What’s our IT plan for the next twelve months, and how does it connect to the business plan? Where are we on the technology lifecycle, and what’s the replacement schedule? What’s our current cybersecurity posture, and what’s changed since last review? What are the top three risks in our environment right now, and what are we doing about each? Where is shadow IT or shadow AI showing up, and how are we responding?

If those questions get answered crisply, without scrambling, you’ve handed off a function. If they get answered with “let me get back to you” or “we’d need to look into that,” you’ve got a dispatcher, not an owner.

This question becomes especially important for organizations responsible for managing client data, whether due to insurance requirements, legal obligations, or commitments made to clients about how their information is managed. 

What Is AI Data Residency? 

Data residency refers to the geographic location where your data is physically stored. When you type a prompt into an AI system, the data can be processed on servers anywhere in the world. If those servers are in Canada and owned by a Canadian company, the data remains in Canada and will be subject to Canadian Privacy Law, including PIPEDA. If the data is stored at rest on servers in another country, the data may be subject to that country’s privacy laws.  

However, due to the Cloud Act in the United States even if the server is in Canada, the US government can gain access to that data if the server is owned by an American company. This does not mean that the US government has unlimited access to data stored on American owned servers. It also does not mean storing data with American companies violates PIPEDA. It is, however, important for business leaders to understand who can access their data under what circumstances. 

For Canadian business owners, data residency is not just a technical detail – it affects privacy obligations, client trust, and risk exposure.  Business leaders have the ultimate responsibility of ensuring they have a well-configured and secure account to protect client data, regardless of where the data is stored. 

ChatGPT and Canadian Data Residency 

If employees are using the free version of ChatGPT, their data is generally stored and processed in the United States. The same applies to lower-tier paid plans such as Plus and Team. These plans do not currently offer Canadian data residency meaning that company information entered into those accounts is primarily handled through U.S.-based servers and may be subject to further American legislation, such as the Stored Communications Act. 

Paid plans do offer stronger privacy controls than the free version. For example, business subscriptions can limit whether the data is used to improve public models. This is an important distinction for companies that are concerned about confidential information being reused by the model. Even with these improvements, the data storage is still primarily stored outside of Canada. 

ChatGPT Enterprise is where things change. Enterprise and Education customers have the option to store their data “at rest” in Canada or other supported regions.  

In practical terms, if Canadian data residency is a requirement for your organization, Enterprise deployment is currently the only ChatGPT option that supports it. Even then, it is important to understand that some limited technical processing or metadata may still occur outside Canada. As with all global cloud systems, this is an unavoidable and common practice.  

The key takeaway for Canadian businesses is straightforward: the safety of ChatGPT for business use depends heavily on the subscription level, how it is configured, and what information your team enters into it. 

Microsoft Copilot and Canadian Data Residency 

Microsoft Copilot operates within your organization’s Microsoft 365 environment. For many Canadian organizations already using Microsoft 365, this simplifies the conversation around AI data residency. 

If your organization’s Microsoft tenant is configured in Canada, Copilot generally follows those same regional settings. It also operates within Microsoft’s enterprise security framework, meaning your business data is not used to train public AI models and remains inside your organization’s boundary. 

However, configuration still matters. If your tenant is not set up with Canadian data residency, your data may be stored elsewhere. If your Microsoft 365 environment is in line with your organization’s needs, then your Copilot license will be as well. 

Enabling Copilot can be a great opportunity for businesses to review their security settings. If you are concerned about data residency and security with AI, Copilot is considered the safest option. 

Google Gemini and Canadian Data Residency

Google Gemini, integrated into Google Workspace, follows a similar pattern as Microsoft Copilot. Business-level subscriptions provide administrative controls and do not use company data to train public AI models. Data residency depends on how your Google Workspace environment is configured. 

If your organization has selected a Canadian region for data storage, your information will remain there. If not, it may be stored in another country. Like Copilot, the product itself is only part of the equation. The way your environment is set up determines where your data lives. 

For Canadian companies evaluating Gemini, the right question is not simply whether the tool is secure, but rather if your Google configuration aligns with your data residency expectations. 

The Real Risk: Unmanaged AI Use 

In many organizations, the biggest risk is not the AI platform itself.  Instead, it is the absence of structure around how employees are using it. 

Across Canada, staff are experimenting with AI every day. They paste client emails into ChatGPT to rewrite them. They summarize financial data. They draft HR responses. They brainstorm strategy documents. Most of the time, employees are trying to be more productive, not careless. 

The issue is that leadership often has no visibility into this activity. There is no approved tool, no clear policy, or guidance on what can and cannot be entered into AI systems. Without this regulation, an organization can lose control of their data without realizing it. When it is unmanaged, risk grows quietly in the background. 

Canadian business owners must consider whether the AI use inside their organization is intentional and governed. When companies standardize approved tools, understand AI data residency in Canada, and set clear internal guidelines, AI can be used confidently and securely.  

Does Data Residency Matter for Every Business? 

Just because your company’s data is stored on servers outside Canada does not automatically make it unsafe. Large cloud providers such as OpenAI, Microsoft, and Google operate highly secure global infrastructure. In many cases, these international data centers have stronger physical and digital security controls than what most small or mid-sized businesses could ever implement internally. 

For many Canadian businesses, especially those in less-regulated industries, storing data in the United States may present little practical risk. U.S.-based cloud infrastructure is mature, secure, and widely used by Canadian companies every day. 

Where data residency becomes more important is in situations such as: 

• Highly regulated industries 

• Government or public sector work 

• Organizations with strict contractual data location requirements 

• Businesses handling sensitive personal, health, or financial information 

In those cases, the data can carry legal, contractual, or reputational implications. For others, it may simply be a matter of preference rather than necessity. The key is understanding what regulations you are bound by and what you can do to ensure your tools aren’t compromising your commitments to data security. 

A More Balanced Way to Think About AI and Data Location 

AI adoption does not need to be driven by fear. It should be driven by informed decisions. 

International cloud systems are not “less secure” simply because they are outside Canada. In fact, the global infrastructure operated by major providers is designed to meet extremely high security standards. Encryption, access controls, monitoring, and compliance certifications are standard practice. 

Instead of asking if foreign servers are dangerous, business leaders need to ask if the organization has legal, regulatory, or contractual reasons to keep data in Canada. 

If the answer is yes, then Canadian data residency should be part of your AI decision-making process. 

If the answer is no, the focus may shift more toward choosing the right subscription level, setting clear internal policies, and ensuring employees are using approved tools appropriately. 

Sources 

• Data residency and inference Residency for ChatGPT | OpenAI Help Center 

• Gemini Enterprise Standard and Plus Editions data residency and ML regional processing commitments  |  Google Cloud Documentation 

• Data Residency for Microsoft 365 Copilot and Copilot Chat – Microsoft 365 Enterprise | Microsoft Learn 

That era is ending, and some leaders haven’t caught up to what’s replacing it.

Your cyber insurer is quietly becoming one of the more consequential auditors of your IT environment. Not in the traditional sense, where someone gives you a finding and a remediation date. The underwriter’s audit is the one that runs after an incident, when the question isn’t “what do we fix by Q3” but “does the policy actually pay.”

Look at what’s driving the shift. The Insurance Bureau of Canada reports that Canadian cyber premiums climbed from $18 million in 2015 to $550 million in 2023. And yet from 2019 through 2023, insurers paid out roughly $1.53 in claims for every $1 they collected in premium. That’s not a sustainable book of business. It’s a market that has to tighten or collapse, and tightening is what we’re seeing.

Tightening doesn’t only mean higher prices. It means underwriters are now grading deployment depth, not checkbox presence. They want to know not just whether you have MFA, but whether it’s phishing-resistant, and whether it’s deployed on the accounts that matter. They want to know not just whether you have endpoint detection and response (EDR), but what percentage of your laptops, workstations, and servers it actually covers. Marsh McLennan’s 2025 cyber risk study put numbers on it: each 25% jump in EDR coverage cut breach probability by 10%, and phishing-resistant MFA users were 9% less likely to suffer a cyber event than those on weaker MFA. Underwriters have read that study too.

Then there’s the part that should make every leader pause. Coalition’s 2024 claims data found that 82% of denied cyber insurance claims involved organizations that hadn’t fully implemented the MFA they had attested to.

Read that again. Most denied claims came from organizations that thought they had coverage. They paid the premium. They filed the policy. Then something went wrong, the adjuster came in, and the gap between the application and the environment was wide enough to deny the claim.

For Canadian leaders the picture is sharper still. A 2025 IBC and Angus Reid survey found that only 22% of Canadian small and mid-sized organizations carry any form of cyber insurance, and just 12% hold a dedicated stand-alone policy. Meanwhile 72% of those same respondents said AI is making cyber risk harder to defend against. So most organizations are underinsured, increasingly exposed, and walking into a market that is getting pickier about who it covers and how much it pays when something goes wrong.

What does this mean for the work?

The renewal conversation is no longer a procurement exercise. It’s a controls conversation. And the questions worth bringing to it aren’t mostly about price. They’re about proof.

Can you demonstrate, today, that the controls you attested to last year are deployed the way you described? Not in theory, in the policy document, but in the actual environment, on the actual endpoints, for the actual accounts. If a claims adjuster walked in tomorrow and pulled the configuration of your MFA, your EDR coverage, your backup retention and isolation, and your admin account hygiene, would the picture match the application?

Some of the ambiguity is on the application itself. Older policies asked broad questions (“are all accounts protected by MFA?”) that were difficult to answer cleanly in a real environment with service accounts, legacy systems, and vendor exceptions. Newer applications are getting more specific (“all email accounts protected by MFA”), which helps, but the language still varies policy to policy. Part of the work at renewal is reading carefully enough to know what you’re actually attesting to.

Where would an adjuster find a gap? Because there is often a gap. The acquired entity that hasn’t been fully integrated. The line-of-business system whose vendor still doesn’t support modern MFA. The shared service account everyone forgot about. The backup job that’s been failing silently for six weeks. These are the gaps that don’t matter on a normal Tuesday and matter enormously on the Tuesday something goes wrong.

A useful exercise before your next renewal: take last year’s application and walk through the attested controls with your IT team or partner. For the ones that are clearly worded, ask for evidence (a configuration export, a coverage report, a screenshot) that they’re deployed the way the application described. For the ones that are ambiguous, get aligned on how you’re interpreting the question before you sign the next attestation. The deltas you find are the deltas the adjuster would find.

The policy you think you have is the one that pays if those two pictures match.

The trouble is, buying the tool isn’t the job. Running it is.

We’ve watched this pattern play out in IT security and backup for twenty-five years. An organization licenses the right products, the dashboards turn green, and everyone moves on. Then something goes wrong, and the gap between “we have the tool” and “the tool actually did its job” turns out to be wider than anyone realized.

Backup is the cleanest example. Industry surveys consistently find that a meaningful share of organizations who go to restore from backup don’t get all their data back. The [2024 State of the Backup Survey](https://drj.com/industry_news/2024-state-of-the-backup-survey-says-security-incidents-and-data-loss-on-the-rise/) found that only 42% of organizations who experienced data loss recovered all of their data on restore. These are organizations with backup systems in place. The tools were running. The jobs were completing. The restore still came up short. Somebody, somewhere, looked at a green dashboard last Tuesday and told themselves things were fine.

The tool isn’t the thing. The human running it is.

At Smart Dolphins we run a centralized services team whose whole job is making the tech, security, and backup stack do what it claims to do. We human-verify backup jobs daily. Not “the dashboard says green,” but a person confirming the job ran, the data is recoverable, and yesterday’s quiet failure isn’t sitting there waiting to ruin somebody’s week. That sounds unglamorous because it is. It’s also the part of the work that determines whether the protection you’re trusting in is real on the day you actually need it.

The same logic applies to patching, to endpoint protection, to spam filtering, to identity and access. Each of those tools has a dashboard. Each dashboard can be green while something underneath is quietly broken or misconfigured or drifting out of policy. The work of catching that drift isn’t done by the tool. It’s done by someone whose job is to look, verify, tune, and fix.

So when you’re thinking about your own setup, whether that’s your MSP, your internal IT team, or the security stack you’ve been told is handled, the question worth sitting with isn’t which tools you have. It’s who’s watching them, tuning them, and verifying them on a Tuesday afternoon when nothing is on fire. That Tuesday afternoon work is what determines whether the tool is an asset or an expensive illusion.

Buying tools is easy. Running them is the actual job, and it always has been.

That’s the kind of thing some leaders say when they’re thinking about their IT setup. No crisis. No systems on fire. Just a quiet, hard uncertainty that a lot of leaders share but rarely say out loud. And there’s one simple question that can reframe the thinking productively:

“What percentage of the work your team or IT provider does for you is reactive versus proactive?”

One question. But the answer reshapes how you think about the effectiveness of your IT budget, and it gives you a sentence you can take straight to your board or leadership team: “Right now, 70% of our IT spend is keeping things from falling apart. 30% is building stability, capacity, and new capability. Here’s our plan to shift that over the next twelve months.” Decision-makers understand that framing instantly.

The distinction that matters

Reactive work is everything that happens after something breaks: tickets, outages, emergency calls. It’s necessary, but it’s pure expense. You’re paying to get back to where you were before the problem happened.

Proactive work is the other side. Most people assume that means patching, backups, and hardware planning — the defensive layer that prevents future fires. That matters. But usually the bigger value comes from aligning technology with where your organization is heading, redesigning a workflow that’s costing your staff hours every week, surfacing opportunities you didn’t know were available because you’ve been too deep in the day-to-day to look up.

Proactive work that only prevents problems is optimization. Proactive work that opens up new capacity or improves how your organization operates is opportunity. If your IT function is only doing the first kind, you’re leaving a lot on the table.

What the answer tells you

If the work is mostly reactive, that doesn’t necessarily mean your team or provider is failing. Some organizations have years of accumulated technical decisions creating a heavy reactive load, and the environment needs to be stabilized before proactive efforts can gain traction. But now you know, and knowing gives you a starting point: what would it take to shift the ratio? What proactive work has been deferred? Where should you invest intentionally instead of absorbing whatever comes?

If the answer is mostly proactive, ask whether that work maps to your actual strategic priorities or just a standard checklist applied regardless of context. If your team or provider can’t draw that line, the work needs to be revisited.

Turning the ratio into a tool

Here’s what this can look like in practice. Imagine an organization sitting at roughly 80/20, reactive to proactive. That’s not unusual. After about eighteen months of intentional work — stabilizing the environment, retiring old systems, putting monitoring in place — an organization like that could realistically get somewhere between 50/50 and 20/80. Total monthly IT spend might go up significantly, but the number of disruptions staff deal with could drop dramatically. In practical terms, that often looks like an administrative team reclaiming dozens of hours a month that had been eaten by workarounds, manual processes, and waiting on broken systems.

That recovered capacity is where the real story is. It’s what lets a team finally launch the program expansion they’ve been deferring, or redirect staff time toward work that actually moves the mission forward.

That’s a fundamentally different budget conversation than “we need more money for IT.”

Knowing the ratio also creates accountability in a healthy way. If you agree together that the goal is to shift from 70% reactive to 50% reactive over the next year, you’ve got something concrete to track. Not as a gotcha, but as a shared objective — something both sides can look at quarterly and make decisions around together.

You don’t need a fancy assessment to start. Just ask this fundamental question. See what your team or provider says. If they can answer clearly and specifically, that’s a good sign regardless of the ratio. If they can’t, that tells you something too.

AI use is already happening in most organizations, whether it’s formally approved or not. Without clear expectations, employees make individual judgment calls about what data to use, how outputs are applied, and whether results are reviewed. 

This creates real challenges: 

• Data risk from sensitive information entered into public tools  

• Inconsistent outputs and client experience  

• Lack of accountability for outcomes  

• Duplicated effort across teams  

The result is increased risk, wasted time, and uneven return on AI investment. 

Unstructured AI use also creates opportunity cost. Teams work in isolation, repeat mistakes, and fail to scale what works across the organization. 

AI policy is a key step in moving from ad hoc experimentation to consistent, reliable use. 

Pillar 1: Make AI Use Visible 

Understanding Shadow AI 

Shadow AI refers to AI use that happens informally, without oversight or defined expectations. It often emerges because employees are trying to work more efficiently without clear guidance. 

This can compromise sensitive information or degrade the client experience. 

Common Risky Use Cases 

Examples include: 

• Publishing client-facing content generated by AI without proper review  

• Summarizing internal reports using public tools  

• Entering internal or client data into AI tools without understanding how that data is handled 

Creating Visibility into AI Usage 

The first step in governing AI is visibility. Leaders should acknowledge that AI is already part of daily work and take a simple inventory of where and how it is currently being used. 

This is often done through an internal survey. The goal is to surface existing use cases and identify where guidance is needed. 

Building Guidelines for Safe AI Use 

Organizations may choose to approve specific tools or define which use cases are appropriate in different environments. 

The goal is to allow teams to experiment safely while ensuring sensitive workflows are handled within secure tools. 

Encouraging Shared Learning and Transparency 

Creating a shared space for AI learnings helps teams build capability together. For example, a dedicated Teams channel can be used to share workflows, prompts, and lessons learned. 

This allows organizations to monitor usage patterns while helping teams learn from each other. 

Reducing Risk Through Transparency 

Shadow AI creates risk when usage is hidden. Encouraging transparency reduces that risk and helps organizations scale AI use more effectively. 

Pillar 2: Ownership and Accountability 

One of the biggest gaps in AI governance is ownership. When no one owns AI, decisions become fragmented and risks go unnoticed. 

Most organizations benefit from defining two roles: 

• AI Owner: Oversees usage patterns and ensures governance is addressed at a leadership level  

• AI Adoption Lead: Helps teams apply AI in real workflows and supports ongoing adoption  

These responsibilities can sit within existing roles and typically require only 1–2 hours per week. 

What matters is clear ownership and a defined path for support and escalation. 

Pillar 3: AI Principles 

Draw Principles from Your Values 

AI principles should be grounded in company values and focused on behavior, not technology. They should be simple, practical, and easy to apply. 

Examples of Practical AI Principles 

• AI-generated work is reviewed before being shared externally  

• AI supports decision-making but does not replace accountability  

• AI is used to improve efficiency without sacrificing quality  

• AI outputs are reviewed with the same scrutiny as a new employee’s work  

Guiding Decisions in New Situations 

AI policies cannot cover every scenario. Principles help teams make decisions in new or evolving situations while staying aligned with company expectations. 

Pillar 4: AI Policy Contents 

Positioning the Policy as a Practical Guide 

An AI policy should function as a practical guide, not a legal document. It should be clear, concise, and grounded in real workflows. 

Core Elements of an AI Policy 

At a minimum, an AI policy should include: 

• The purpose of AI within the organization  

• AI principles  

• Approved and prohibited uses  

• Expectations for review and oversight  

• Ownership and governance structure  

• How and when the policy will be updated 

Keeping Policies Usable and Relevant 

Policies that are too complex or disconnected from daily work will be ignored. Clarity and usability should be the priority. 

From Control to Capability 

AI is becoming a core business capability, similar to email or cloud platforms. Organizations that succeed do not rely on informal experimentation. They build light, intentional structure through visibility, ownership, shared principles, and practical policy. 

The goal of AI governance is confidence, not restriction. When expectations are clear, teams can use AI effectively, responsibly, and with less risk.

Not directly, usually. It shows up sideways, in conversations at industry events or over coffee. “So, 25 years… what’s next?” The question carries a set of assumptions. Guy in his 50s, been at it a while, business is doing well. The script says this is where you start thinking about an exit. Cash out. Slow down. Enjoy the fruits.

I get it. And I’ve watched a lot of my peers follow that script. Some were tired. Some hit a ceiling they didn’t want to push through. Some just saw a good offer and took it. I don’t judge any of that. Everyone’s working with their own set of circumstances, and selling a business you built is a legitimate choice that can change your life in meaningful ways.

But it’s not my choice. At least not right now. And I think the reasons why might be worth sharing.

There’s a common philosophy in business: build it like you’re going to sell it. Get your systems tight, your team strong, your financials clean. Make the thing attractive to a buyer. Here’s what’s funny about that. It’s the same logic as fixing up your house to put it on the market. You finally renovate the kitchen, paint the trim, stage everything just right. Then you walk through it and think… why am I selling this place? It’s never been better.

I think the same thing applies to a business. If you do the hard work of building something that doesn’t revolve around you, that runs well, that creates value for the people in it, you’ve built something worth keeping. The very things that make it sellable are the things that make it worth owning and the things that make it worth continuing.

And I think that’s where some business owners get stuck. It’s not that owning a business is inherently draining. It’s that they built one that needs them at the centre of everything. Every decision, every client relationship, every fire. That’s exhausting after 15 or 20 years. Of course you want to escape that.

But the escape impulse might be a symptom, not a solution. Selling doesn’t fix the pattern. It just ends it.

I’ve tried, imperfectly and over a long time, to build Smart Dolphins so it doesn’t need me in the middle of things. Not because I was planning to leave, but because I think that’s just a better business. It’s better for the team. It’s better for clients. It’s better for me. I get to choose where I put my energy instead of the business making that choice for me.

So when I think about what I actually want, it’s not an exit. It’s flexibility. Working from somewhere warm for a couple months in the winter. Spending my time on things that matter most rather than whatever’s on fire. Still learning, still being challenged by new problems.

That probably sounds simple, but getting there has been the work of 25 years. And I’m still working at it!

Here’s what I’ve come to believe, though. A business built with intention can actually be one of the most freeing things in your life. You have a place to be productive and creative. You’re connected to people you care about. You have problems worth solving. What does selling give you? A blank calendar. Some of the people I know who sold eventually went looking for something similar to fill it.

I’ve watched peers cash out, enjoy life for six months or a year, and then start circling back. Some started consulting. Some got into private equity. Some started new businesses in the same or adjacent industry they just left. Which always makes me wonder: what if they’d just kept building what they originally built?

I’ll be honest. There have been hard stretches where I wondered if I should move on. Big challenges that tested me. Times where I genuinely wasn’t sure I could lead the next version of this company. A growing business asks things of you that you haven’t learned yet, and that gap can feel pretty permanent when you’re in it.

But I think most of those ceilings are ones we build for ourselves. We get comfortable. We mistake familiarity for limitation. The skills and growth required to lead a bigger, more complex business aren’t genetic. They’re learnable. The question is whether you’re willing to do the uncomfortable thing.

And look, when you’ve been at it this long and things are going well, coasting is tempting. Just protect what you’ve built. Stay comfortable. But the stretches I look back on most fondly aren’t the easy ones. They’re the ones that cost me sleep. The ones where I wasn’t sure it would work out. Doing hard things doesn’t feel meaningful while you’re in it. It does after.

Writing 25 insights from 25 years has a feeling of finality to it. Like I’m packaging up the lessons and putting a bow on things. But I might only be halfway through. There’s a lot of runway ahead, and I have a belief that some of the most interesting chapters are still ahead.

I’m not naive about that. The world changes. Circumstances change. Maybe something happens that makes selling the right call. I’m open to that possibility. But I’m not looking for an exit. I’m not building toward a finish line. I’m building toward more of what I already love: a great team, work that matters for clients that matter, interesting problems, and the room to keep evolving how I show up in all of it.

So no, I’m not retiring. I’m not done.

Can’t wait to write 50 insights from 50 years.

What’s this 25/25 stuff about?: 25 YEARS, 25 INSIGHTS – Reflections on Growth, Leadership and Resilience | Smart Dolphins IT Solutions Inc.

We have a tradition of giving core value awards – recognizing three Dolphins who exemplify our three core values. It is intended to be a way to celebrate and reinforce what matters to us. I try to keep it light and fun and try to make it about the team. But in practice, one Dolphin winning means other Dolphins don’t. I could feel it. This wasn’t reinforcing our “Elevate the Team” culture. These awards were working against it. So we’re stopping it. It’s a small thing. But these small things matter.

I think about that moment because it captures something I’ve learned over 25 years: culture work is never done. It IS the work. You can get something right for a while, and then it drifts. Or you set something up with good intentions and it creates the wrong effect. You have to keep paying attention. Keep adjusting.

But the ongoing nature of culture work isn’t just about adjusting what you’re doing. It’s about going deeper into understanding who you actually are.

Culture doesn’t start with picking aspirational statements and ranting about them to the team. It starts with really knowing yourself. What you genuinely care about. What behaviors feel natural to you. What kind of environment you intrinsically want to work in every day.

That sounds straightforward, but it’s not. It’s intimate and uncomfortable as you dig into deeper layers. It requires real honesty about who you are versus who you think you should be. It’s easy to pick aspirational values that sound good. It’s much harder to acknowledge what you actually value in practice.

We spend time thinking about who we are and what we want to emphasize in our stated core values. Put them on paper. Share them with the team. Highlight example behaviors. Hire and fire around them. We genuinely try to identify what’s true to us, not just what sounds impressive.

But it feels like a life-long journey to fully understand myself and our team. I thought I valued certain things. I thought I was a certain kind of leader. And some of that was true. But some of it was who I wanted to be, not who I actually was.

That gap creates problems. Your real values show up in your decisions whether you acknowledge them or not. You can say you value one thing, but if your actual behavior contradicts that, everyone sees it. And then the stated values become meaningless.

So the work of knowing yourself keeps going deeper. You learn things about yourself by watching what you actually do. By noticing what makes you uncomfortable or upset. By seeing patterns in your decisions. By paying attention to the moments when you make important decisions and examining why.

The discovery work isn’t just about you as the leader either. It cascades. The leadership team needs to know themselves individually and as a collective. To understand their own values and behaviors. To see where they’re aligned and where they’re not.

And then it extends to the whole team. Culture is ultimately about who you are as a group. What you believe together. How you behave as a group. That can’t be manufactured from the top down. It has to be discovered and built through who you bring in and how everyone shows up.

We have three core values at Smart Dolphins: Love Your Dolphin Life. Elevate the Team. Find a Better Way. Those aren’t aspirational statements. They describe who we actually are. They came from watching ourselves, not from brainstorming what would sound good.

The business changes. Your team changes. You change. So the understanding keeps going deeper. You think you’ve figured something out, and then you realize there’s more to learn. You can’t separate culture work from the work of understanding yourself and your team more deeply. They’re the same thing.

Once you know who you are – or at least who you are right now – the hardest work begins. You have to make decisions that align with that.

The real cultural work happens in people decisions. Who you hire. Who you keep. Who you address when they’re off track. Who you ask to leave. Every one of those decisions teaches your team what you actually value, regardless of what’s on the wall or in the handbook. Those decisions get really hard when performance and culture don’t align.

One of my mentors, Gary Pica, says “you get what you tolerate.” I’ve proven that true more times than I’d like to admit.

We’ve gotten more disciplined about this. We do quarterly reviews where the leadership team evaluates every person against our core values and their role. When someone is “off track” – a phrase that’s become meaningful here – we address it.

That sounds systematic. But it’s not easy. It’s hard every time. Especially when someone has been with you for years. Especially when they’re good at their job but misaligned in how they work or what they believe about how we should do things.

This is where culture actually gets built. It’s not in the moments when you talk about your values. It’s in the moments when living those values is impactful and you make the decisions consistently with those values.

We also try to reinforce culture in smaller, repeated ways. We have a peer recognition system where people acknowledge each other for living our values. It’s active – people use it regularly. And it spreads the work of culture beyond just leadership. These points of recognition are usually related to our values and culture – they’re meaningful.

Recently we did 360-degree reviews for our leadership team. All five of us scored highly. The feedback showed real alignment, appreciation and trust. It felt like validation that the work is real, not just aspirational.

The moments that define culture are the ones that cost you something. Saying no to revenue because a prospect doesn’t fit. Addressing a top performer’s behavior even though it’s uncomfortable. Catching yourself reinforcing the wrong thing and being willing to change it.

I don’t think you ever “finish” building culture. You’re always discovering more about yourself and your team. Always making decisions that either reinforce what you believe or contradict it. Always adjusting as things drift or as you learn something new. And if you’re paying attention, you keep getting better at it.

What’s this 25/25 stuff about?: 25 YEARS, 25 INSIGHTS – Reflections on Growth, Leadership and Resilience | Smart Dolphins IT Solutions Inc.

The way many businesses buy IT sets them up to fail. And the industry enables it.

I know how that sounds coming from someone who sells IT services. So let me acknowledge the bias upfront. Of course I want businesses to invest in IT and choose Smart Dolphins as their partner. Of course this perspective serves my interests. That doesn’t make it untrue.

Here’s the pattern I’ve seen hundreds of times. An organization decides they need better IT support. They’re frustrated with their current provider or they’ve outgrown their internal IT person. So they start a search.

And almost immediately, they approach it from a position of insecurity. They’re afraid of being taken advantage of or buying the wrong thing. And they don’t fully understand what they’re buying or what it should cost. So they try to control the process. They build comparison spreadsheets. They focus on price. They ask for detailed quotes on specific deliverables or perhaps they want an assessment or a project as a test run. They want to dictate the terms. They might even create a… gulp… complicated RFP.

This approach can feel like being smart and careful. But what they’re actually doing is selecting for providers who will tell them what they want to hear instead of what they need to know. And they’re making it difficult for anyone to actually lead them to better results.

Here’s what a real IT partnership actually looks like. A provider that knows your business well enough to connect technology decisions to your actual goals. They can tell you “no, that’s not the right solution for what you’re trying to accomplish” and explain why. They take ownership of outcomes, not just tasks. When something breaks, they don’t just fix it, they figure out why it broke and prevent it from happening again. They document everything important. They plan ahead, with you. They tell you about problems you don’t know you have yet.

Most importantly, trust runs both directions. You trust them to make good decisions on your behalf. You let them lead. They trust you to invest in what’s actually needed.

That kind of relationship requires real capability and maturity on the provider’s side: leadership who understands business, not just technology. Structure and process that protects proactive work, not just reactive firefighting. Financial stability that allows investment in team and systems. The experience and confidence to push back on clients when it’s the right thing to do.

But when businesses optimize their buying process around price and control, they make it difficult for capable providers to really lead them to better results. The businesses that get great IT results don’t approach it that way. They recognize they don’t know what they don’t know. They look for competence and maturity, not the lowest bid. They give their provider room to actually do the work, they let them lead. They treat it as a partnership, not a transaction.

I’ve been on both sides of this dynamic. In Smart Dolphins’ early years, we took on clients at prices that didn’t support the level of service we wanted to provide. We meant well. We worked hard. But we too often couldn’t execute on what we promised. The economics didn’t allow it. It was frustrating for us and limiting for our clients.

The shift happened when we stopped trying to meet every prospect where they were and started being clear about what good IT actually takes. We said no to prospects who wanted to control every detail of the engagement. We stopped selling itemized services and started selling a holistic relationship. We invested in becoming the kind of provider that could consistently deliver on our promises.

And we lost plenty of prospects and even some clients. Businesses who weren’t ready to invest in IT as strategic went elsewhere. That was a little unnerving at first, but we knew it was necessary. In the end, we gained better clients, better relationships, and the ability to actually deliver solid results… and peace of mind for all.

Here’s what changed for those clients. Their teams became more productive because technology actually worked the way they needed it to. Their leaders stopped worrying about IT and started focusing on their business. Problems got prevented instead of just patched. When they needed to make technology decisions, they had someone who understood their business well enough to guide them. Their IT became predictable, quiet, reliable, strategic.

You can’t buy that on the cheap. You can’t get strategic results from a transactional relationship. And you can’t optimize your way into great IT by controlling every detail and making it difficult for your provider to lead.

The hardest part is that you won’t know the difference until you’ve experienced it. When you’re stuck in the transactional or reactive dynamic, it’s hard to imagine what the alternative even looks like. The problems feel normal. The frustration feels like just part of dealing with IT. And it’s often worse than you realize given the inherent cyber risks that come along for the ride.

But once you experience what’s possible when the relationship is actually working, when you have a partner you trust who understands your business and takes real ownership of outcomes, the transactional approach stops making sense.

I hesitated to write this because some people may read it as self-serving. Maybe it is. But after 25 years of watching businesses make the same mistakes and learning what actually works, I think it’s worth saying.

The way you approach buying IT matters more than you probably realize. The insecurity that drives the process is often what prevents you from getting what you actually need.

What’s this 25/25 stuff about?: 25 YEARS, 25 INSIGHTS – Reflections on Growth, Leadership and Resilience | Smart Dolphins IT Solutions Inc.