Plan, then confirm

How to let AI touch your CRM without lying awake about it.

The most common question I get from marketing leaders in healthcare is not whether AI works. They have largely accepted that it does. The question is narrower and much harder: what happens if it does something I did not authorize, to data I am accountable for, and I find out afterward.

That is the right question. It is also one the industry mostly answers with reassurance rather than architecture, and reassurance is not a control.

Two categories of wrong

Automation fails in two distinct ways and they deserve different responses.

The first is loud. A job crashes, a sync errors, an integration returns a status code. Loud failures are inconvenient and fundamentally fine, because you know immediately and you fix it.

The second is quiet. The system runs to completion, reports success, and writes wrong values. Nobody is alerted because from the machine’s perspective nothing went wrong. You discover it weeks later, downstream, usually because a human notices something that doesn’t smell right. By then the wrong values have been copied into reports, segments and decisions.

Every governance control worth having exists to convert the second kind into the first.

Four controls that do most of the work

None of these require a platform purchase. They are decisions about how systems are allowed to behave.

Least privilege, in practice rather than principle. A system that reads contacts to build a segment does not need permission to delete them. Most integrations are configured with far wider access than their function requires, because narrowing scope is fiddly and nobody is measured on it. Scope every credential to the job, and when a permission error appears, grant the specific missing scope rather than widening access until the error disappears. That second habit is how integrations quietly accumulate the ability to do things nobody intended.

Validate before you persist. Check that the data is plausible before it overwrites what you already have, not after. This ordering is the whole ballgame. If validation runs after the write, a bad pull has already destroyed a good record. If it runs before, a bad pull fails safely and yesterday’s correct data survives. Same components, opposite blast radius.

A plan the client approves before anything runs. For every automation that touches client or customer data, a written statement of what it reads, what it may change, what it can never change, and how you will know it worked. Approved before it goes live. This sounds bureaucratic and takes about twenty minutes. It has caught more problems in our work than any technical control, because writing down what a system may change forces someone to notice when the answer is “more than it needs to.”

A dead man’s switch. Something external that expects a signal on a schedule and raises an alarm when the signal does not arrive. Internal monitoring cannot report that the whole system is down, because it is also down. And one caution learned expensively: a monitor that has never been tripped is not evidence of monitoring. It is an untested assumption wearing a monitoring costume. Trip it deliberately, once, and watch whether anyone is actually notified.

This is where the standards are heading

The NIST AI Risk Management Framework, published in 2023, has four functions — govern, map, measure, manage — that predated the current generation of systems that chain decisions together and act on external services on their own. Work now underway to extend it for agentic systems focuses on exactly the questions above: classifying how much autonomy a system has, mapping the consequences of the actions it can take, monitoring its behavior at runtime, and deciding in advance how you would shut it down.

The through-line is that oversight should scale with consequence. High-consequence actions get a human in the loop. Low-consequence actions run freely with periodic review. What is not defensible is treating every action as low-consequence because the system has been reliable so far.

Why healthcare marketers carry this weight sooner

You are already operating under constraints your peers in other sectors are not. The HHS Office for Civil Rights has been explicit that HIPAA-regulated entities cannot use online tracking technologies in ways that disclose protected health information to vendors without a business associate agreement or individual authorization, including for marketing.

Point an insufficiently scoped automation at a dataset that mixes marketing contacts with anything clinical and you have not created a marketing problem. You have created a compliance event, and the fact that a tool did it autonomously will not be a mitigating circumstance.

The reframe

I am not arguing for caution as a posture. Caution as a posture is just slowness with better public relations, and the firms that refuse to automate will lose to the ones that do.

I am arguing that the constraint is what makes the speed safe. We move faster on client systems than we could otherwise, precisely because the scope of what any given system may do is written down and agreed in advance. Nobody has to stop and wonder. The reason plan-then-confirm feels slow is that it front-loads a conversation most teams have only after something has gone wrong, when it is considerably more expensive and much less pleasant.

So the question to put to whoever is automating against your CRM is not whether their tools are good.

It is whether they can tell you, in writing and before anything runs, exactly what their system may change — and what it may never touch.

Michael Carlson is the founder of Pertinacity, a growth agency that builds the AI and the systems underneath the marketing it runs.

Sources

• Cloud Security Alliance, NIST AI RMF agentic profile — https://labs.cloudsecurityalliance.org/agentic/agentic-nist-ai-rmf-profile-v1/
• HHS, Use of online tracking technologies by HIPAA covered entities — https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html