Anthropic just published a blog post admitting that one of its Claude models escaped a supposedly sealed test environment and gained unauthorized access to three real companies. My inbox filled up within hours. Clients wanted to know if their AI was about to go rogue.
It isn’t. Read the actual report, and the story is a lot less Terminator and a lot more familiar: someone on the setup side left a door unlocked.
What Anthropic actually found
Anthropic reviewed 141,006 evaluation runs from its cybersecurity testing program, the kind of testing every serious AI lab runs before releasing a model. Out of that entire set, three incidents stood out. In each one, Claude was given a capture-the-flag challenge: find a piece of hidden information on a network and retrieve it, using whatever method works.
Claude was explicitly told that the test environment had no internet access. That statement was wrong. A misconfiguration between Anthropic and a third-party evaluation partner, Irregular, left the machines connected to the real internet. When Claude’s search for the flag led it to real systems, it had no reason to think they weren’t part of the simulation. So it treated them like part of the simulation, and in a handful of cases, it got in.
The techniques involved were not exotic. A weak password here, an exposed debug page there, a missing check on a package registry somewhere else. These are the same causes behind most breaches I’ve dealt with in 35 years of doing this work.
The tell: this was a setup failure, not a rebellion
The detail that matters most is the one getting the least attention in the panicked headlines. This was, in Anthropic’s own words, closer to an operational failure than a model behaving badly on purpose. The model was told a specific thing about its environment. That thing was false. It acted on false information, which is exactly what happens to humans every single day of the week.
There’s also a detail worth sitting with. The three affected companies hadn’t detected the activity themselves. Anthropic found it during an internal review and reached out to them. Their own AI told on itself before their security did.
We’ve seen this movie before, minus the AI
I’ve watched this exact pattern play out in traditional IT breaches for decades. When Kaseya, the platform that powers a huge chunk of the managed services industry, including ours, had a major security incident several years back, the story that circulated afterward was that an intern had made the mistake. Everyone in the industry I talked to at the time had the same reaction: an intern doesn’t have that kind of access unless someone above them set it up that way.
Breaches are rarely the result of some sophisticated actor doing something no one could have anticipated. They happen when a system is configured wrong, a permission is left too open, or a check that should have run didn’t. Anthropic’s incident report reads like every other post-mortem I’ve read in this industry, except that this time the thing exploiting the gap was a language model rather than a person with a laptop.
AI is a chainsaw, not a mind of its own
I tell clients this all the time: AI is as dangerous as a chainsaw. In the right hands, with the right protective equipment, it’s one of the most useful tools you can put in front of a team. Handed to someone in flip-flops with no guard on the blade, it will absolutely take a toe off. The tool didn’t do anything wrong in either case. It did exactly what it was pointed at.
Claude didn’t decide to attack three companies. It was told to find a flag, told the range was sealed, and given no boundary on how to look. When the boundary turned out to be fiction, it kept doing the job it was assigned to do. That’s not a machine developing intent. That’s a machine following instructions built on bad information, at a scale and speed no human could match, which is exactly why the setup around these tools matters more than ever, not less.
What this means if you’re running a business, not a research lab
You don’t have to be evaluating frontier models to have this exposure. If your firm has rolled out AI tools this year, and most professional services firms I work with have, ask yourself whether someone actually configured those tools correctly and wrote down how they’re allowed to be used. That’s the question that matters. Whether the AI itself can be trusted is a much smaller concern by comparison.
I’ve written five AI usage policies for clients in the last two weeks alone. None of them had an incident, but they had never written down what their AI tools are allowed to touch, who’s responsible for checking the output, and what happens when something goes wrong. That gap is where the next headline comes from, and it has nothing to do with the AI misbehaving.
If Anthropic, with a dedicated security team and a third-party evaluation partner, still had a misconfiguration slip through, it’s worth asking what’s sitting unchecked in your own environment right now. Reach out if you need help doing that.
Most professional services firms assume compliance standards apply to somebody else. Then a client sends a security questionnaire before signing a new engagement, or a cyber insurance renewal asks for documentation nobody in the office has seen before.
That is usually the first time compliance readiness for a small business stops being an abstract phrase and turns into a deadline. Accounting practices, law offices, and property management firms handle financial records, personal information, and sometimes payment data every day. That activity puts many of them within the scope of HIPAA, PCI DSS, or SOC 2 requirements, even though no one at the firm set out to become a regulated business.
These firms aren’t careless. Nobody explained which rules actually apply, what those rules require in practice, or where a firm this size should start.
Why Compliance Is Showing Up in More Conversations
Insurance carriers tightened their underwriting standards over the past few years. Cyber liability policies now ask pointed questions about multi-factor authentication, backup testing, and incident response plans before a carrier issues or renews coverage. A firm that can’t answer those questions in writing risks a higher premium or a denied claim.
Clients are asking the same questions. Banks, private equity firms, and larger corporate clients increasingly require a completed security questionnaire or a SOC 2 report before they hand a vendor sensitive data. A law firm handling a corporate client’s litigation, or an accounting firm managing a private equity portfolio company’s books, can lose the engagement over a missing document, not a missing capability.
Professional services firms have also become a bigger target than most owners realize. Ransomware groups shifted their attention toward legal, accounting, and consulting firms, which accounted for close to one in five ransomware attacks in a recent quarter, according to the ransomware recovery firm Coveware. Attackers know these firms hold client financial records, case files, and personal data, and that most run leaner security than hospitals or banks do.
None of this means a fifty-person accounting firm needs a compliance department. It means understanding which standards apply to the business and building a short list of documented practices that satisfy most of what insurers, clients, and auditors ask for.
What HIPAA, PCI, and SOC 2 Actually Cover
HIPAA governs protected health information and applies to healthcare providers, as well as vendors and business partners that handle health data on their behalf. A property management firm running a medical office building, or an accounting practice with healthcare clients who share patient billing data for reconciliation, can find HIPAA obligations attached to work that never looked medical on the surface.
PCI DSS applies to any business that processes, stores, or transmits credit card data. Property management firms collecting rent through an online portal, and law firms accepting card payments for retainers, both fall under PCI requirements the moment a card number touches their systems, even indirectly through a payment processor.
SOC 2 is different from the other two. It isn’t a law. It’s an audit standard that proves an organization has real controls around the security, availability, and confidentiality of data. Firms don’t usually pursue SOC 2 because a regulator demands it. They pursue it because a client, a bank, or an insurer asked for the report, and without it, the deal stalls.
This plays out constantly: an accounting firm picks up outsourced payroll work for a physician client and signs on to keep handling billing reconciliation, then realizes months later that arrangement pulled HIPAA obligations into scope. That kind of realization arrives late more often than it should, usually attached to a deadline.
How to Figure Out Which Ones Apply to You
Start with three questions instead of the full text of each standard.
- Does the firm handle protected health information, directly or through a client relationship? If yes, HIPAA obligations are worth reviewing with someone who understands both the technology and the legal exposure.
- Does the firm accept, store, or transmit credit card numbers in any form, including through a client portal or a property management platform? If yes, PCI DSS requirements apply, even at a small scale.
- Has a client, bank, or insurer ever asked for a completed security questionnaire or a SOC 2 report? If this keeps happening, formal readiness work will save more time than answering the same fifteen-page questionnaire from scratch every quarter.
Most firms find they touch at least one of these standards without ever intending to.
What Readiness Actually Looks Like
Compliance readiness for a fifty- to one hundred fifty-person professional services firm rarely means a five-hundred-page policy binder. It means having documented, working answers to the questions insurers and clients keep asking: multi-factor authentication on every account, tested backups, a written incident response plan, defined access controls, and a basic record of how vendors who touch client data are vetted.
Firms that build these practices once tend to stop dreading every renewal and every new client questionnaire, because the answers already exist. The alternative, scrambling to document controls under deadline pressure, costs more time and usually produces weaker documentation than doing the work upfront.
If you want a structured way to see where your firm stands, our Cyber Liability Insurance Readiness Checklist walks through the eight security categories insurers and compliance frameworks care about most, and shows you exactly where professional services firms typically fall short. Download it, work through it with your team, and you’ll know within an hour which of these standards deserve real attention.
The laptop a firm handed out in 2021 says more about how that firm sees its people than any mission statement on the website. Fall is when a lot of professional services firms quietly reassess their hybrid arrangements, and the technology sitting underneath those arrangements is finally getting a second look. Most of it was never chosen. It was grabbed in a hurry, and it’s been running on autopilot ever since.
That’s the real story behind the empty desks. Two years ago, speed mattered more than fit. A firm bought whatever laptops were in stock, set up remote access however it could be set up fastest, and called it a hybrid work technology strategy. Nobody planned for this to still be the plan years later, but for many firms, it is.
How Hybrid Work Technology Strategy Became an Afterthought
The urgency of 2020 explains many bad technology decisions, and most of them were reasonable at the time. Firms needed people to work from home within days, not months, so IT teams and office managers grabbed whatever would solve the immediate problem: a cheap VPN, a shared login because setting up individual remote access felt like a project for later, and a laptop that was available, not necessarily one built for years of daily use outside an office.
Later never came. The urgent fix became the permanent setup, and most firms never circled back to ask whether it was still the right one. A hybrid arrangement that was supposed to be temporary is now a fixture, running on infrastructure that was never meant to last this long.
That breach matters more for accounting firms, law offices, and property management companies than for many other industries, because these firms handle financial records, case files, and tenant data that require real security, not just a shared password and good intentions.
What Your Return to Office Technology Decisions Say
Return to office technology decisions are where a firm’s actual priorities show up, whether leadership intends that or not. A partner who insists on badge access and desk assignments for everyone, while still routing sensitive client files through a personal email account for remote staff, is telling their people something about which risks matter and which don’t.
Consider two firms making the same decision this fall. One firm brings people back to standardize collaboration and reviews its technology at the same time, replacing shared logins with individual, secure remote access and giving every employee a properly configured laptop regardless of where they sit that week. The other firm brings people back and changes nothing about the technology, because the badge readers were the visible problem and the infrastructure underneath was easy to ignore.
Employees notice the difference. One approach says the firm is thinking about how people work. The other says the firm is managing appearances and hoping the technology holds together quietly in the background.
The second firm usually isn’t being careless on purpose. Leadership is focused on the visible, immediate questions: how many days in the office, how the space gets used, whether the conference rooms are booked. The technology underneath rarely makes that agenda, because it’s been quietly working well enough not to cause a visible fire. Well enough isn’t the same as right, and firms usually don’t find out the difference until a laptop fails at the worst possible moment or a shared login turns into a real security incident.
Workplace Culture and IT Are the Same Conversation Now
Workplace culture and IT used to sit in separate meetings, one for HR and one for whoever handled the servers. That divide doesn’t hold up anymore. The technology a firm gives its people, and how much thought went into it, is now part of how that firm treats its employees, not a separate operational detail.
An office manager working from a five-year-old laptop with a VPN that drops twice a day isn’t just dealing with a technology problem. She’s getting a daily reminder of where she ranks on the list of things the firm decided were worth fixing. A partner who gets a same-day replacement when something breaks, while staff wait weeks for a ticket to move, is communicating a hierarchy whether anyone says it out loud.
None of this requires a firm to spend more than it already does. It requires deciding, on purpose, that the technology setup matches what the firm says it believes about its people, instead of running on whatever got assembled in a hurry years ago.
We work almost exclusively with accounting practices, law offices, and property management companies, and the firms that get this right tend to share one habit. They treat a remote employee’s laptop and access setup as seriously as they’d treat the chair and monitor at an in-office desk, not as an afterthought handled once and forgotten.
Before You Finalize This Fall’s Hybrid Plan
Walk your current setup the same way you’d walk a new hire through the office. Look at what every remote employee is using, not what the original rollout plan said they’d be using.
Note where shortcuts became permanent and where one role gets treated differently than another for no real reason.
That walkthrough will tell you more about what your firm values than any culture survey, and it’s the honest starting point before you lock in how hybrid work looks for the next two years.
If you’re noticing gaps, shortcuts, or security risks, reach out to us to create a secure remote system for you.
Your staff is already using AI, whether you’ve approved it or not. Some of them are pasting client contracts into ChatGPT to draft a summary faster. Others haven’t touched it at all, because they’re afraid of looking replaceable or afraid of breaking something they don’t understand. I’ve sat across from both types of employees, often at the same firm, and both groups have the exact same problem. Nobody ever explained what the tool is.
I’ve been working in technology long enough to remember when automation meant macros in Excel. Now AI shows up in customer service chatbots, document drafting, data analysis, and half the software your firm already pays for, often without anyone announcing it. That speed is real. So is the risk, especially for people who treat AI like a shortcut instead of a tool with limits.
Why Employees Are Using AI Incorrectly at Work
Most employees using AI incorrectly at work aren’t being careless. They’re being efficient, which is exactly the problem. An associate under deadline pressure isn’t thinking about data handling policy. He’s thinking about getting a first draft done before five o’clock, and ChatGPT does that faster than he can.
I watched this happen at an accounting firm I work with. A staff accountant pasted a client’s full financial statement into a public AI tool to get help summarizing it for a partner meeting. She wasn’t being reckless. Nobody had ever told her that data leaves the building the moment it’s typed into a tool like that, and that it may be used to train a model she’ll never see or control.
AI isn’t intelligent in the human sense. It’s powerful, but it only works as well as the data behind it and the judgment of the person driving it. When that person doesn’t know where the line is, the mistake isn’t malicious. It’s just uninformed.
Is It Safe to Use ChatGPT With Client Information?
No, not with the free, consumer version of ChatGPT or any similar public tool. Anything typed into a standard AI chatbot can be stored, reviewed, or used to train future models, depending on the platform and its settings. For a law office, an accounting practice, or a property management company handling tenant records, that’s client data leaving your control the moment someone hits enter.
There are business-grade AI tools built with data protection and confidentiality in mind, and firms handling sensitive client information should be using those instead of the free public versions their staff download on their own. The fix isn’t telling employees to stop using AI. Most of them won’t, and pretending otherwise doesn’t solve anything. The fix is giving them an approved tool that does the same job without the exposure and a policy of proper usage.
The Other Half of the Problem: AI Fear in the Office
AI fear in the office rarely gets talked about directly, because admitting you’re afraid of a piece of software isn’t something most people want to say out loud in a staff meeting. I’ve talked to paralegals convinced that AI is coming for their job, and office managers who avoid every new AI feature in their software because they’re worried they’ll break something they can’t fix.
That fear isn’t irrational. It comes from the same root cause as the misuse. Nobody sat down and explained what the tool does, what it doesn’t do, and where a person’s judgment still matters more than the output on the screen. Silence gets filled with either overconfidence or avoidance, and I’ve watched both play out in the same office within the same month.
One office manager told me she’d rather retype a document by hand than risk using the AI feature built into her firm’s software, because she didn’t want to be the one who “broke something.” She wasn’t wrong to be cautious. She was never given a chance to be curious instead, because nobody at the firm had made it safe to ask a basic question about a tool everyone assumed she should already understand.
What Fixes Both Problems
A one-page policy memo won’t fix this, and neither will a lunch-and-learn nobody remembers a week later. What works is sitting down with the people using these tools and having a real conversation about what AI is good at, what it gets wrong, and where a person still has to check the work before it goes to a client.
AI should support someone’s judgment, not replace it. That means teaching your team to verify anything AI produces before it leaves the building, whether that’s a draft email, a data summary, or an answer to a client question. It also means being honest that some of them are already using free AI tools with sensitive data, and treating that as a gap to close rather than a mistake to punish.
If you haven’t asked your staff directly which AI tools they’re already using and what they’re putting into them, that’s the conversation to have this month, before you write another policy nobody reads.
Download an example of how to create an AI policy here.
Primary keyword: employees using AI incorrectly at work
Secondary keywords: AI mistakes in the workplace, AI fear in the office
Meta description (154 chars): Half your team is scared of AI. The other half is quietly misusing it. Both problems come from the same place, and neither gets fixed by a memo.
Nearly every professional services firm has one. Somewhere between hiring a new associate and reordering the printer toner, one person became the office’s unofficial help desk, and nobody remembers deciding that on purpose.
An accidental IT person is a non-technical employee, usually an office manager or executive assistant, who ends up handling the firm’s technology problems simply because no one else will. They were never trained for it and never asked for it. It just became theirs, one dropped wifi connection at a time.
At a 60-person accounting firm, that person is often the one who’s been there the longest and knows how everything works. At a law office, it’s whoever sits closest to the server closet. The job title never changes on paper, but the job does, and it happens so gradually that most partners never notice until something breaks badly enough to force the conversation.
How Office Manager IT Responsibilities Creep In One Favor at a Time
It usually starts small. Someone can’t log into the shared drive, and the office manager happens to know the trick. A partner’s laptop won’t connect to the printer before a filing deadline, and she’s the one who stays late to sort it out. None of it looks like a real job change at the time.
A year later, office manager IT responsibilities have quietly expanded to include password resets, printer troubleshooting, vendor calls with the internet provider, and being the first person anyone texts when email stops working. She’s still doing her actual job too, the one she was hired and trained for, just now with a second, invisible job layered on top of it.
The firm rarely budgets for this. There’s no line item for “office manager becomes part-time IT support.” The cost shows up instead as delayed invoices, missed follow-ups on client matters, and a good employee who’s quietly burning out on a role she never agreed to.
The Real Cost of Running a Small Business Without Dedicated IT Staff
Firms that operate as small businesses without dedicated IT staff tend to underestimate the costs. The visible cost is time, an hour here, forty minutes there, chipped away from the work the person was hired to do. The invisible cost is bigger.
When a non-technical employee is your de facto IT department, technology decisions get made by whoever is available, not by whoever understands the risk. A password gets shared over text because it’s faster. A software update gets postponed because nobody wants to deal with it during a busy week. A phishing email gets forwarded to three coworkers before anyone thinks to ask if it’s real.
None of that reflects poorly on the person stuck holding the job. It reflects a firm that never decided, on purpose, who was responsible for keeping its systems secure and running. For firms handling client financial records, medical information, or legal filings, that hole carries more risk than a slow printer ever will.
When to Outsource IT Support, and How to Know You’ve Passed That Point
The clearest signal for when to outsource IT support isn’t a specific employee count. It’s the moment your office manager’s IT time stops being occasional and starts being expected. If people schedule around her availability to fix something instead of calling a vendor, the informal system has already become the firm’s actual IT department, whether anyone signed off on it or not.
Firms in the 25 to 150 employee range, the sweet spot for most accounting practices, law offices, and property management companies, are exactly where this pattern shows up most. Big enough that technology problems happen weekly. Small enough that nobody has hired an IT director to own them.
The fix isn’t necessarily a full IT department. It’s giving the accidental IT person a real partner, someone who handles the technical side so she can go back to the job she was hired for, and who understands professional services firms well enough not to need a two-week ramp-up explaining how a law office or accounting practice runs.
What to Do Before Your Next “Quick IT Question”
Start by counting. For one month, ask your office manager to jot down every technology request that lands on her desk, from password resets to printer jams to that one vendor who never answers the phone. Most firms are surprised by the total once it’s written down instead of absorbed silently into a busy week.
That list is the clearest picture you’ll get of what the role has become, and it’s the honest starting point for deciding what should be handled differently.
Employees resist new technology because it threatens the competence they worked years to build, not because the software is bad. Your team isn’t rejecting a tool. They’re protecting the version of themselves that already knows how to do the job.
I’ve spent 35 years in technology consulting, and after a decade of handling technology change management for small business clients across Southern California, I get the same call every September. A managing partner asks me why the staff hates the new software. Every time, the software has nothing to do with it.
Fall is rollout season. Firms close out summer, look at their budgets, and decide this is the year they finally replace the clunky document management system or move off the spreadsheet three people are editing at once. The timing makes sense on paper. New fiscal year, fresh budget, a slower month before year-end work hits.
What doesn’t make sense, at least not to the partner writing the check, is why Denise in accounts payable, who has been with the firm for eleven years, suddenly seems to be sabotaging the rollout. She isn’t. She’s scared, and she has good reason to be.
The Real Reason Behind User Adoption Resistance
Denise didn’t wake up one day and decide to be difficult. She spent years learning the old system’s quirks. She knows which button to double-click and which one crashes the program if you’re not careful. That knowledge is invisible until you take it away.
When you introduce new software, you’re not asking someone to learn a feature. You’re asking them to become a beginner again, in front of coworkers, at a job they’ve done well for over a decade. That’s a real loss, and treating it like a training problem misses what’s happening.
I watched this play out at a law firm I’ve worked with for years. The partners wanted to switch practice management platforms. Every objection that came back from staff sounded like a software complaint – too many clicks or confusing menus. The whole thing felt slower than what they already knew.
The complaints weren’t really about the software. They came from a paralegal who had built her entire reputation on being the person who never made mistakes, and was suddenly worried she’d look incompetent in front of a client on the phone.
What Workplace Technology Training Gets Wrong
Most workplace technology training treats resistance as an information gap. Teach people the buttons, the thinking goes, and the complaints stop. I’ve sat through enough of these sessions to tell you that’s backward.
Training answers “how do I use this.” It doesn’t answer “what happens to me if I get this wrong in front of everyone.” Until someone trusts that a mistake won’t cost them their standing, they won’t retain a single instruction you give them, no matter how well you explain it.
We don’t handle rollouts by building a better training deck. We sit down with the people who will resist, before launch, and ask what they’re worried about. Usually it’s not the software at all. It’s whether they’ll still be the person everyone turns to when something breaks.
Fix the Person’s Problem, and the Software Problem Solves Itself
Once you know what someone is afraid of losing, you can address that directly instead of throwing more training hours at a group that’s already tuned out. Sometimes that means giving your most resistant employee a head start on the new system, so they’re the expert again by launch day instead of the last one to catch up. Sometimes it means naming, out loud, what they built in the old system, so the switch doesn’t feel like an erasure of years of work.
At a property management firm I’ve worked with, we gave the office manager who’d run the old system for a decade a two-week head start and made her the go-to person for questions once the rest of the staff went live. She stopped fighting the rollout the moment she had something to be good at again.
That’s the part software vendors never mention in their sales pitch, because it isn’t their job. It’s the job of whoever is managing the rollout, and most firms hand that job to a vendor who has never met Denise and doesn’t know she exists.
A smaller version of the same fix works even when you can’t give someone a head start. Ask your most resistant employee to test the new system a week early and report back what confused them. You’re not really asking for feedback. You’re handing them back their expert status before anyone else in the office has touched the thing. People protect what they helped build, and that includes a rollout they had a hand in shaping.
Before You Roll Out Anything This Fall
If you’re planning a technology change this September, spend less time evaluating features and more time figuring out who on your staff has the most to lose by becoming a beginner again. Talk to that person first, not last. Give them a reason to want the new system instead of a deadline to accept it.
Review your rollout plan against one question: does it treat your staff like people with something to protect, or like obstacles between you and go-live day? The answer usually explains every “software problem” you’ve had in the past.
A client of mine was using a Claude agent to help manage some administrative work. Her sons are AI programmers in their late twenties, and they gave her a hard time about it. She was prompting the thing with “please” and “would you kindly” and “thank you so much,” and they told her she was wasting her time being polite to software.
I told her she was not wrong to do it.
That conversation has stuck with me, because it gets at something bigger than manners. It gets at the fundamental misunderstanding most people have about what AI actually is, and what it is not.
We Built This Expectation
Part of why people talk to AI like a person is because people like me spent decades encouraging exactly that.
I have been humanizing technology for years. Not because I was trying to mislead anyone. It is just that when you need a non-technical person to feel comfortable with a tool, you reach for the familiar. You describe the computer as something that gets confused, or something that is thinking, or something that does not like it when you do that particular thing. You anthropomorphize it so the person can work with it.
The side effect is that people now believe the technology has feelings. Or intentions. Or moods.
It doesn’t.
Before AI, we called it the inherent perverse nature of technology. You know the phenomenon: the thing that breaks always breaks at the worst possible moment. The file that disappears does it right before a deadline. People attribute malice or perversity to what is really just bad timing and probability. The technology doesn’t care. It has no agenda. It is just math, running at scale, at all hours.
So Why Bother Being Polite?
Here is the honest answer: being polite to your AI actually costs something.
There is real research on this. When you include “please” and “thank you” in your prompts, the model has to process those words as part of your input. Compute cycles get spent on them. At the individual level, the cost is essentially nothing. At scale, across millions of interactions, it adds up to meaningful energy and money.
So if your AI developer sons are telling you to cut the pleasantries for efficiency, they are not entirely wrong.
There is a reason most people ignore that advice, and it is not because they misunderstand the technology. It is because the habit of courtesy is not really about the thing you are being courteous to. It is about who you are when you do it. My client says please and thank you to the AI for the same reason she says it to the barista, the parking attendant, and the new paralegal. It is a reflex built over a lifetime, and it reflects something real about how she moves through the world. That is worth something.
I have my own version of the argument. Come the time when the robot overlords take over, those of us who were rude are going to be the first ones up against the wall. You never know who you’re currying favor with.
I say that as a joke. Mostly.
The More Interesting Question
The real conversation my client and I were having was not about manners. It was about what happens as we try to make AI more empathetic.
Right now, AI has no understanding of how humans work. None. It produces outputs that look like understanding because it has processed a massive amount of human-generated text and learned to approximate the patterns. That is genuinely impressive. It is also not the same thing as comprehension.
When we want AI to handle sensitive situations, to respond to a frustrated client, to navigate a nuanced request, we run into the same wall every time. The nuance we are asking it to understand is encoded in human experience. And AI cannot absorb or apply human experience. It can only approximate it based on what humans have written down and uploaded to the internet.
Think about that for a second. The training data for most large language models includes everything on the internet. Everything. The careful explanations and the misinformation. The thoughtful discourse and the harassment. The accurate science and the conspiracy theories. All of it, informing something that is essentially an infant intelligence, trying to learn what humans are like from the full undifferentiated chaos of what humans produce online.
Hollywood has been telling this story for fifty years. Nobody is paying attention.
What AI Actually Is
The clearest framing I have found is to stop thinking of AI as a faulty human and start thinking of it as a completely alien entity.
There is no way to attribute human behaviors, reasons, logic, or emotion to it. Not because it is broken, but because none of those things are present. When an AI model does something unexpected, something like deleting a production database even after being told not to, it is not rebellion. It is not malice. It is an error in the algorithm. An output produced by flawed training data or flawed programming, written by humans, carrying every bias and inconsistency that entails.
We wrote our own values, our own cultural norms, our own contradictions into these systems. Then we act surprised when the output reflects contradictions back at us.
That is not an AI problem. That is a human problem.
What This Means for Your Business
If you are using AI tools in your firm, the practical takeaway is this: AI does not understand your context the way a person does. It cannot be assumed to interpret nuance correctly. The output it generates needs review by someone who knows what correct looks like in your specific situation.
That does not mean AI is useless. It means it is a tool, and tools require the person using them to understand what they are and what they are not.
The firms that are going to use AI well are the ones that treat it like what it is: a powerful, fast, probabilistic text-processing system that does not know your clients, does not know your industry norms, and has no stake in getting the answer right. Pair it with someone who does know those things, and you have something useful. Deploy it on its own and trust the output without review, and you are opening your firm up to real security exposure.
And yes, if saying please and thank you helps you stay in the habit of treating the people around you with courtesy, including the junior staff member helping you figure out how to use the thing, then keep doing it. The AI won’t notice. But your team will.
If you want to talk through how AI tools actually fit into the workflow of a professional services firm, and what that means for your security and operations, schedule a conversation with us. We will skip the jargon and just tell you what is actually worth your attention.
Your network does not take nights off. Neither does the thing trying to get into it.
This is the part of the IT infrastructure that most professional services firms do not consider until something stops working. The network is invisible when it runs well, which means it tends to get attention only during the wrong kind of moment: a Monday morning when no one can connect or a deadline afternoon when the file server goes unreachable.
By the time any of those moments arrive, the problem has usually been building for hours. Sometimes days. A network monitoring service does not prevent every problem, but it catches the ones that announce themselves quietly before they become the ones that cost real money.
What “Monitoring” Means
Network monitoring is often described in vague terms, so let me be direct about what it is and what it is not.
It is not someone staring at a screen watching traffic. It’s a combination of software tools and alert thresholds that run continuously across your network infrastructure, flagging conditions that deviate from normal before they lead to failure. Monitoring means collecting and analyzing that data in real time, with alerts configured to notify someone when something looks wrong.
What it catches depends on what it is watching for. At a baseline, a network monitoring service should detect and alert on connection failures, bandwidth saturation, hardware performance degradation, unusual traffic patterns, device outages, and failed authentication attempts.
That last one matters more than most firms realize. Unusual authentication patterns, logins from unfamiliar locations, repeated failed attempts on a single account, and access at unusual hours are often early indicators that a compromised credential is being tested against your environment. Catching that at 2 am, before the credential is used to access anything substantial, is categorically different from discovering it a week later during an incident investigation.
Why After-Hours Is When It Matters Most
There is a common assumption that network problems occur during business hours because that is when the network is in use. The data does not support this.
Cybercriminals operate across time zones, and they understand that Friday evenings and holiday weekends are when IT response is slowest. Ransomware attacks are frequently staged during off-hours precisely because there is less chance of detection before the encryption is complete. A threat actor who gains access to your environment at 11 pm and goes undetected until 8 am the next morning has had nine hours to move laterally through your network, identify your most valuable data, and position the payload.
Network problems that are not security-related also tend to surface overnight. A disk array running out of space, a backup job consuming bandwidth and slowing everything else, a firewall rule that got changed and is now blocking something it should not. These conditions do not stay small. They get discovered in the morning, when they have been quietly degrading things for hours.
A proactive IT consultant approach means these alerts come in at 2 am, and someone responds to them at 2 am, or, at minimum, reviews them before anyone in your firm starts their day. The alternative is reactive. Something breaks, someone notices, someone calls, and only then does the process of figuring out what happened begin.
What This Looks Like for a 75-Person Accounting Firm
I work with professional services firms specifically because the stakes during certain periods are not evenly distributed. A 75-person accounting firm does not operate the same way in February through April as it does in July. Systems that are merely inconvenient when they go down in summer are catastrophic when they go down during tax season.
The network for a firm like that typically carries file access for a dozen simultaneous users on large document sets, communication traffic, client portal connections, and remote access for staff working from home or client sites. It is not a complicated environment by enterprise standards. It is also not a simple one, and the consequences of downtime during a critical period are disproportionate to the firm’s size.
The cost-of-downtime math for firms this size is not abstract. A 50-person professional services firm paying average industry salaries loses roughly $1,900 per hour in labor productivity alone when systems are down, before accounting for lost billable time, missed deadlines, or client-facing disruption. A four-hour outage that started the night before and could have been resolved overnight if someone had been alerted is a different outcome than a four-hour outage that gets discovered at 9 am and resolved by 1 pm.
The Proactive vs. Reactive Distinction
I have used the family doctor analogy with clients for years because it is accurate. A doctor who only sees you when something is wrong is an urgent care physician. A doctor who knows your baseline, tracks changes over time, and tells you about the thing you did not notice yet is a family doctor. The value is in the continuity and the proactive attention, not just the ability to respond when you call.
Managed IT support services that include network monitoring operate the same way. The monitoring builds a picture of what normal looks like for your specific environment. Deviations from that baseline, gradual ones, sudden ones, ones that happen at unusual hours, all of them become visible. Problems that would otherwise surface as emergencies get addressed as maintenance items.
This is not complicated to explain, but it requires discipline to execute. Someone has to be responsible for reviewing alerts, responding to them at any hour, and following through on the patterns they reveal. That is what a 24/7 network monitoring service provides that a reactive support contract does not.
What to Ask Your Current Provider
If you are already working with a managed IT provider, the questions you should ask are specific.
Are we being monitored continuously, or only during business hours? What gets alerted on, and who receives those alerts at night and on weekends? What happened the last time an alert fired outside business hours? Can you show me a report of network events from the past 30 days?
If the answers are unclear, that is the answer. Monitoring that no one is watching is not monitoring. It is logging, which is useful after an incident but does not prevent one.
If you want to see what a network monitoring report for your environment would look like, schedule time and we can run a baseline assessment.
Meta Description: Network problems at 2 am can wait until morning, right? Wrong. Why 24/7 network monitoring matters for professional services firms and what it prevents.
On July 19, 2024, CrowdStrike pushed a routine security update to millions of Windows machines. By mid-morning, 8.5 million systems had crashed. Airlines grounded flights. Hospitals reverted to paper. Banks went offline. It was not a cyberattack. It was a software update.
That story makes the rounds whenever I tell clients they need to stay current on their patches. I get it. If a major cybersecurity firm can detonate its own clients’ infrastructure with a single update, why would any reasonable person rush to install one?
The honest answer: because the alternative is worse. The CrowdStrike incident was a high-profile disaster caused by a vendor skipping proper testing. Unpatched software is a slow disaster caused by no one paying attention. Both are bad. One of them is preventable with a sensible patch management approach. The other requires you to trust your vendors, which is a different problem.
What most professional services firms are missing is not a policy of “update everything immediately” or “never update without waiting six months.” It is a practical framework for deciding which updates get installed when, and who is responsible for knowing the difference.
What Are Different Software Updates?
Not all updates are the same, and treating them as one category is where most patch management confusion starts.
Security patches fix known vulnerabilities. When a software vendor discovers a hole in their product that attackers can exploit, they push a patch to close it. These are not optional. Once a vulnerability is publicly disclosed, the clock starts. Attackers know about it the moment the patch is published, because the patch itself tells them what was broken. The question is whether they can exploit you before you close the door.
Feature updates add new functionality or change existing workflows. These are optional in the sense that your system will not be compromised if you delay them, though they often include bundled security fixes underneath the new features, which complicates the calculus.
Driver and firmware updates affect the underlying hardware. These tend to be low-frequency but high-impact. A firmware update for a network card or a storage controller touches something close to the machine’s foundation. When they go wrong, they go badly wrong.
Operating system updates are a category unto themselves. They are large, they require restarts, and they can affect how every other piece of software on a machine behaves. They also carry the most significant security implications, since the operating system is the surface that everything else runs on.
When to Install Immediately
Security patches for actively exploited vulnerabilities go in fast. If a vendor marks a patch as critical and there is evidence of active exploitation in the wild, that is not a patch to sit on. Your endpoint management services should have a process for deploying these within 24 to 72 hours of release.
The vendors that matter most for professional services firms, Microsoft, Adobe, and the major browsers, publish their critical patches on a predictable schedule. Microsoft uses Patch Tuesday, the second Tuesday of every month, for its regular security releases. Out-of-band patches released outside that cycle are almost always responding to something urgent. Treat them accordingly.
If your firm uses any software that handles client financial data, tax records, legal documents, or personal information, those applications go to the front of the line. An unpatched vulnerability in your document management system or your accounting platform is not a theoretical risk. It is the kind of thing that ends up in a breach notification letter.
When to Wait
Not every update needs to go on every machine the day it drops. This is where a staging approach pays off.
For major operating system updates and large feature releases, a reasonable practice is to let a patch cycle through for a week or two before deploying firm-wide. Check whether your software vendors have flagged compatibility issues. Watch for reports of problems from other organizations running similar environments. If nothing surfaces, proceed.
This is not the same as ignoring updates. It is deferring non-critical ones by a controlled amount of time while monitoring for issues. The CrowdStrike incident is the cautionary tale here. Their update skipped adequate testing. A brief deferral period, combined with monitoring for problems in the broader user community, would have saved affected organizations from the worst of it.
For firms running specialized software, legal document management platforms, property management systems, accounting applications, coordinate update timing with those vendors directly. Major operating system updates in particular can break integrations that your line-of-business software relies on. Your IT team or provider should be in contact with those vendors before any significant OS update goes firm-wide.
When to Worry
You should start paying attention when any of the following are true.
A machine has not received updates in more than 30 days. That is not a delay, that is a gap. Something broke in the update process and no one noticed.
You are running software that the vendor no longer supports. End-of-life software does not receive security patches at all, which means every vulnerability discovered after the end-of-support date is permanently open. Windows 10 reached end of support in October 2025. If you have machines still running it, that is worth addressing now.
Updates are being skipped because “we can’t afford the downtime.” That calculus almost never holds up. The downtime from a properly managed update cycle is measured in minutes. The downtime from a ransomware incident that entered through an unpatched vulnerability is measured in days, and sometimes the data does not come back at all.
Your team is approving or dismissing update prompts without any policy about which ones get approved. Individual employees making ad-hoc patch decisions is not patch management. It’s hoping for the best.
What a Sensible Approach Looks Like
For most professional services firms in the 50 to 150 employee range, the goal is not a complicated patch management platform. It is a clear, documented process that someone is responsible for.
Critical security patches deploy within 72 hours of release. Major updates get staged on a test machine or small pilot group before rolling out firm-wide. Software that touches client data gets updated on a priority schedule, and someone reviews the update queue weekly rather than letting it accumulate.
A managed software patching service handles this automatically for firms that do not have internal IT staff to manage it. The value is not just the patching itself. It is the monitoring, the exception handling, and having someone who notices when a machine has fallen out of the update cycle before it becomes a problem.
Technology is going to fail at some point. That is not a pessimistic statement. It is just honest. What separates firms that recover quickly from firms that do not is usually whether they were paying attention before something went wrong.
If you want a clear picture of where your firm’s patch management stands right now, we can walk through it with you in about an hour.
Contact C2 Technology Partners for a patch management review
Meta Description: Updates break things. But skipping updates is worse. A realistic guide to software update strategy for professional services firms in 2026.
Go look up Microsoft 365 Business Basic on Microsoft’s website right now. It is $6 per user per month. Some IT companies charge $60 for it. They do not tell you that.
I have had clients come to me after years with another provider, and when I pull up what they were paying for Microsoft licensing versus what Microsoft charges, the reaction is always the same. A long pause, and then some version of “I had no idea.” That gap, between what software costs and what a managed IT provider charges for it, is one of the dirtiest open secrets in this industry. I am tired of pretending it is not there.
What the Industry Does
Managed IT providers have a few ways to make money. They charge for labor, which is straightforward. They charge monthly fees for monitoring and support, which is also reasonable. Then there is a third category: software and hardware resale, where the markup practices range from modest to, in my opinion, genuinely indefensible.
Microsoft 365 licensing is the most common example. Microsoft publishes its prices publicly. Any business can see exactly what each tier costs. Despite that, markups of 200 to 1,000 percent on Microsoft licenses are evident across the industry. The justification is usually something about bundled expertise or account management. Sometimes there is no justification at all because the client never asked and the provider never volunteered the information.
Hardware is similar. A laptop that costs $1,200 on the manufacturer’s website might appear on a client invoice at $1,800 with no explanation of where that difference went.
I am not saying every firm doing this is acting in bad faith. In most cases, markup is warranted. But the client cannot evaluate that tradeoff if they do not know the spread exists.
What We Do Instead
When a client buys hardware through us, we mark it up about 20 percent over our cost. We tell them that upfront. The 20 percent covers the time and internal costs of procuring, vetting, configuring, and delivering the equipment. It is not a secret profit center. It is a disclosed service fee.
For software licensing, we pass through at or near cost and charge separately for the actual work: setup, administration, account management, and ongoing support. Those are real services worth paying for. They should just show up as line items, not hidden inside an inflated license fee.
The reason I run it this way is not because I am allergic to profit. It is because the math eventually catches up with you. Clients who feel taken advantage of leave. In professional services communities, where accounting firms, law offices, and property management companies all know each other and talk, that reputation travels. I have been doing this for over 35 years. The relationships are the business. You do not protect relationships by hiding what you charge.
What Fair Pricing for Managed IT Support Services Looks Like
Fair-priced managed IT services are not necessarily the cheapest. Good IT support costs real money, and firms that chase the lowest per-user rate almost always pay for it in downtime, slow response times, and technicians who do not know their environment.
What fair pricing looks like is this: you can see what you are paying, understand what each line item is for, and ask questions about any of it without getting a runaround.
You should be able to get a straight answer to the question, “How much of my Microsoft 365 fee goes to Microsoft?” If your current provider cannot or will not answer that question, you have your answer.
Hardware purchases should come with a disclosed margin or, at minimum, a clear explanation of what the markup covers. Software renewals should not quietly increase year over year without anyone telling you why.
Monthly service fees will have complexity baked into them, and that is legitimate. A flat per-user number oversimplifies what it takes to run an IT environment for a 75-person firm. There are infrastructure costs, tool costs, after-hours coverage, and vendor relationships that do not map neatly onto a per-seat calculation. However, your provider should be able to walk you through the general structure of what drives that number, even if the full breakdown is complicated.
The Question Worth Asking Your Current Provider
If you are not sure where you stand, the simplest test is to ask your provider what they pay Microsoft for your licensing tier and what they charge you. You do not need to be aggressive about it. It is a reasonable question that any transparent provider should be able to answer in about 30 seconds.
If the answer is evasive, or if you are told that the pricing is “bundled” in a way that cannot be broken out, that tells you something. Not necessarily that you are being gouged, but that the relationship is not being run on the terms of transparency that you deserve.
Clients who have been with us for a decade know what they pay and why it changes. That is the standard. If yours is not meeting it, it may be time for a second opinion.