Daniel's been thinking about the unglamorous side of the AI boom. His question this week is basically, when does compliance stop being someone else's problem? He wants to look at it from the small business angle — not the Googles of the world, but the ten-person shop that builds one agentic workflow and suddenly finds itself in a procurement process with a Fortune 500. He's asking whether we're seeing ISO 42001-style requirements show up in contracts for agentic pipeline work yet, and what the first moves look like toward defining governance and interoperability standards for agentic payments. That last one, he says, is in its absolute infancy. So let's start with where the pressure actually comes from, and it's not from regulators first.
It's from the procurement department. That's the thing people keep missing. Everyone watches Brussels or Singapore and thinks compliance arrives as a law. For most small businesses, it arrives as a checkbox in an RFP they weren't expecting to see.
The checkbox they can't tick yet.
Right. And the historical parallel is almost too clean. ISO 27001 started as a voluntary information security standard. Nobody was forced to adopt it. Then enterprises realized they needed a way to verify that their vendors weren't a data breach waiting to happen, and suddenly it became the de facto ticket to the dance. If you touched enterprise data, you had ISO 27001, or you didn't get the contract. It took years, but it happened without a single regulator mandating it.
So the question is whether ISO 42001 follows the same path, and faster.
That's the bet. ISO 42001 is the AI management system standard, published in 2023. It covers governance, risk assessment, lifecycle management of AI systems. It's designed to be auditable, which is exactly what procurement teams want. They can't evaluate whether your agent is safe by reading your code. They can't even evaluate it by reading your documentation, because half the time the documentation describes what the agent was supposed to do, not what it actually does. A certification gives them a third party saying, someone looked at this and it's not a disaster. That's the product.
And how many someones have actually been certified?
A handful. Genuinely. As of mid-2026, ISO 42001 certification is still rare. You can count the certified companies without running out of fingers. Which means if an enterprise puts that checkbox in an RFP today, almost nobody can tick it. That's not a functioning requirement yet. It's a signal.
A signal of what?
Of intent. They're telling the market, we're going to require this eventually, start getting ready. It's the same thing that happened with ISO 27001 in the early days. The first RFPs that mentioned it were aspirational. Then they became conditional. Then they became absolute. The whole cycle took maybe a decade. For AI, I'd guess it compresses to two or three years, because the underlying technology is moving so much faster and the fear is so much more acute.
Fear of what, exactly? What is a procurement officer actually afraid of when they add that checkbox?
The agent doing something they can't explain. Think about what's different between a traditional software vendor and a vendor selling an agentic pipeline. The traditional vendor ships a tool. A human uses the tool. If the tool does something wrong, there's a human who clicked the button, and you can trace the decision path. The agentic vendor ships something that acts. It takes multi-step workflows and executes them autonomously. It might compare invoices, approve payments, route documents, update records. The risk profile changes from tool to actor. That's the phrase I keep coming back to. And the compliance frameworks are scrambling to catch up to that shift.
So the enterprise isn't just worried about data security anymore. They're worried about liability for actions taken by a system nobody was supervising.
And here's the gap that makes this interesting. ISO 42001 was written with traditional machine learning models in mind. The kind of system where you train a model, you validate it, you deploy it, it makes predictions, a human reviews the output. The standard is very good on that. It's got requirements around human oversight, risk treatment, documentation. But an autonomous agent that can take actions in the real world — that's a different beast. The standard doesn't fully cover it yet. So what's going to happen is small businesses will be asked to certify something the standard doesn't quite address. They'll be audited against a framework that's a mismatch for what they actually built.
That's the part that feels like it's going to hurt. The small shop that builds a document-processing agent for a big client. They've got maybe fifteen employees. They've spent two years building something useful. And then the renewal RFP comes through with an ISO 42001 requirement, and they have to either find the budget for an audit and process overhaul or walk away from the contract.
The cost asymmetry is brutal. For a large enterprise, certification is a line item. They've already got compliance staff, they've already got documentation processes, they've already got an audit culture. Adding ISO 42001 means extending what they already do. For a small business, it means building all of that from scratch. You need someone whose job is AI governance. You need risk assessments. You need lifecycle documentation. You need to be able to demonstrate to an auditor that you know what your system does, why it does it, and what happens when it fails. That's real work.
And it's the kind of work that doesn't ship product. Which is fine if you're Accenture. It's existential if you're a fifteen-person shop trying to make payroll.
Right. And the thing is, I'm not even sure it's wrong. If you're an enterprise buying an agent that's going to touch your customers' data or your payment systems, you should want some assurance that the vendor has their act together. The problem is that the assurance mechanism we have wasn't designed for the thing being assured.
So what does a small business actually do? If they see this coming, what's the move?
Honestly, I think the smart ones start building the bones of it before they're asked. Not full certification, but the habits. Document what your agents do. Write down your risk assessments. Keep a decision log. The thing about ISO 42001 is that it's not prescriptive about the technology. It's prescriptive about the management system around the technology. So if you've been running your AI development like a skunkworks project where nobody writes anything down, the transition is painful. If you've been doing even minimal governance, it's less painful.
It's like flossing. The people who did it all along are fine. The people who didn't are in for a rough six months.
That's not a bad analogy. And the other thing is, there's an opportunity here. If you're a small business that gets certified early, you become one of the few companies that can tick that box. In a market where the box is about to become mandatory, being early is a competitive advantage. You're not just a vendor, you're a vendor who can pass the audit. That's worth something in a procurement conversation.
Until the box becomes universal and the advantage evaporates.
Sure. But that's true of every early-mover advantage. The question is whether you can convert it into contracts before the window closes.
Let's talk about the other frontier, because this is where it gets weird. Daniel's right that this is in its absolute infancy. But it's not hypothetical anymore.
No, and this is the part I find most interesting, because there's no ISO 42001 equivalent here. There's no standard at all. With human-authorized payments, we've got decades of infrastructure. PCI DSS for card security. SEPA for European transfers. ISO 20022 for payment messaging. The whole stack is mature. With agentic payments, there's nothing. An AI agent authorizes a payment, and we don't even have agreement on who's responsible.
Who is responsible?
That's the question. Is it the principal who deployed the agent? The platform that built the agent? The payment rail that executed the transaction? If an agent makes a mistake and pays the wrong vendor, who eats the loss? We don't have an answer. We don't even have a framework for arriving at an answer.
And yet the tools are already shipping. What's actually out there?
ZeroHash launched agentic finance tools this year. It's one of the first commercial moves in this space. The idea is that platforms can integrate AI agents for payments. So instead of a human logging into a dashboard and approving a transaction, an agent can do it. And the thing that's supposed to make this work is item-level data. The argument is that if an agent can see individual line items — what exactly is being purchased, from whom, at what price — it can make smarter buying decisions. It's not just executing a payment, it's evaluating the purchase.
Which means the agent needs access to more granular data than a human approver ever had.
Right. And that's the tradeoff. More data means smarter decisions, supposedly. But it also means more data to govern. Every line item the agent sees is a data point that has to be secured, audited, and explained. The governance burden scales with the granularity.
So the pitch is, we'll make your payments smarter, and the hidden cost is, you'll need to document why the agent thought this vendor was the right choice at this price on this day.
And nobody's doing that documentation yet, because there's no standard for what it should look like. There's no audit trail format for agentic decisions. There's no equivalent of a payment message standard. ISO 20022 took decades to get right. The banking industry spent years arguing about message formats before they converged. Agentic payments don't have decades. They're going to have to compress that timeline, because the technology is already out there.
What's the Monetary Authority of Singapore doing? They've been proactive on AI in finance.
They have. MAS has been ahead of most regulators on this. They've got frameworks for AI governance in financial services, they've been thinking about digital assets and payments for years. Their approach is interesting because it's principles-based rather than prescriptive. They say, here are the outcomes you need to achieve — fairness, accountability, transparency — and here's the process you should have in place. They're not writing specific technical standards yet. But their template is probably the closest thing we have to a regulatory model for agentic payments.
And the industry side?
The first moves are about interoperability. Making sure that if one agent platform generates a payment instruction, another platform can understand it. That's the ISO 20022 lesson. The early days of electronic payments were a mess of proprietary formats. Every bank had its own message structure. Interoperability only happened when the industry agreed on shared protocols. Agentic payments are in the proprietary phase right now. Everyone's building their own thing. The first standards will be about making those things talk to each other.
Which is less glamorous than governance, but probably more urgent.
It's the plumbing. You can't govern a system you can't even observe. If every agent platform has its own way of recording transactions, you can't audit across platforms. You can't trace a payment from initiation to settlement. You can't answer the question, who approved this, because the approval trail is scattered across four different systems with four different formats.
So where do small businesses fit into this? Daniel's point was that they'll be early test subjects.
They already are, in a sense. A small business that adopts an agentic payment tool for invoicing or procurement is running an experiment in governance that nobody's written the rules for yet. They're documenting their agent's decisions in whatever format the vendor provides. They're hoping that when the standards arrive, their vendor will update to match. They're taking on compliance risk without knowing what compliance will eventually require.
That's a strange position to be in. You're an early adopter of a technology whose regulatory future is undefined, and you're betting that whatever the future brings, you'll be able to adapt.
And the alternative is to wait. To say, I'll adopt agentic payments when there's a standard. Which is reasonable, except that the early adopters are getting efficiency gains right now. They're automating their payables. They're freeing up staff time. They're making fewer manual errors. The question is whether those gains outweigh the risk of having to retrofit governance later.
I keep thinking about the evolution path here. Right now, agentic payments are mostly pre-approved transactions with a human in the loop. The agent proposes, the human disposes. That's the safe mode. The future is agents with delegated authority and real-time risk assessment. The agent decides, executes, and logs its reasoning. And somewhere in between, we're going to have to figure out where the human sits.
And that's the governance question that nobody's answered. Is human oversight a permanent feature or a stopgap? Do we eventually trust agents to make payment decisions without human review, or is there always a human somewhere in the chain? The answer probably depends on the risk level. A fifty-dollar office supply order is different from a fifty-thousand-dollar contract. But we don't have agreed thresholds. We don't even have agreed categories.
The first definitions will probably come from industry consortia, not regulators. The technology is moving too fast for legislation. By the time a regulator drafts a rule, the technology has changed underneath it. So the industry has to self-organize, the way it did with ISO 20022.
That's my guess too. You'll see a group of payment platforms and agent vendors get together and say, we need a common format for agentic payment instructions. And they'll hash it out in working groups over a couple of years. And then it'll become the de facto standard, and eventually a formal ISO standard. That's the path. It's just going to be compressed.
Compressed how much?
I don't know. ISO 20022 took, what, two decades from initial work to widespread adoption? Agentic payments can't wait that long. The market won't wait. If the standards bodies move slowly, the market will route around them. You'll get a proprietary standard from a dominant player that becomes the default, and then everyone else has to live with it.
That's the nightmare scenario. A single vendor's format becomes the de facto standard, not because it's good but because it's first and everyone's built on it.
And then the governance follows the format. If one platform defines what an agentic payment looks like, they effectively define what gets audited, what gets logged, what gets explained. That's not governance. That's vendor capture.
So the window for getting this right is narrow. The industry needs to define interoperability before a dominant player defines it for them.
And that's why I think the next two years are critical. This is the period where the standards get seeded. The working groups form. The first draft specifications circulate. By the time agentic payments are mainstream, the standards will already be set. The question is who's in the room when they're written.
Which brings us back to small businesses. They're the ones who'll be most affected by whatever standards emerge, and they're the least likely to have a seat at the table.
They're not going to be in the working groups. They don't have the resources. They'll be represented by their vendors, if they're represented at all. And the vendors have their own interests. So the standards will be written by the platforms and the payment rails and the big enterprises, and the small businesses will inherit whatever they produce.
The compliance burden lands on the people who had no voice in designing it.
That's the pattern. It's the same with ISO 42001. The standard was written by large organizations with compliance departments. Small businesses are expected to adapt. Some of them will. Some of them won't. The ones that don't get locked out of enterprise contracts.
Let me ask you something. Do you think this is actually going to make AI safer, or is it just going to create a paperwork industry?
I think it's going to do both. The standard itself is not unreasonable. Having a management system around your AI, documenting your risks, thinking about lifecycle — those are good practices. They do make systems safer. But there's also going to be a whole industry of consultants and auditors who make their living helping companies pass certification. Some of that will be valuable. Some of it will be box-ticking. The same thing happened with ISO 27001. There are companies that improved their security posture because of it, and there are companies that bought a binder full of policies they never read.
The binder is the product.
In some cases, yes. And that's the risk with ISO 42001. If it becomes a procurement checkbox, there's pressure to treat it as a formality. Get the certificate, put it on the website, move on. The substance gets lost.
Which would be worse than no standard at all, because it creates the illusion of safety without the safety.
A false sense of assurance is more dangerous than acknowledged uncertainty. If an enterprise thinks their vendor is certified and therefore safe, they might not do their own due diligence. And if the certification doesn't actually cover agentic behavior, the gap is invisible.
So the standard needs to evolve. It needs to catch up to the agentic reality.
And it will. Standards do evolve. ISO 27001 has been revised multiple times. ISO 42001 will get there too. The question is whether it gets there before the market moves on. If agentic pipelines become the dominant form of AI deployment before the standard addresses them, we've got a mismatch that persists for years.
Let's talk about the payments side a bit more. What does an agentic payment actually look like right now, in practice?
The simplest version is an agent that has access to a payment method and a set of rules. The rules say, you can pay invoices under five hundred dollars without human approval, as long as they match a purchase order. The agent checks the invoice against the purchase order, verifies the vendor, and executes the payment. The human reviews the log afterward. That's the pre-approved, human-in-the-loop model. It's not fully autonomous, but it's automating the part that used to take a human ten minutes per invoice.
And the more sophisticated version?
The more sophisticated version gives the agent more discretion. Instead of just matching invoices to purchase orders, the agent evaluates whether the purchase makes sense. It looks at item-level data. It compares prices across vendors. It might negotiate. It might decide to delay a payment to manage cash flow. That's the version ZeroHash and others are building toward. The agent isn't just executing, it's deciding. And that's where the governance questions get hard.
Because now you're asking the agent to make judgment calls that a human used to make, and you need to be able to explain why it made the call it made.
And the explanation isn't just for the auditors. It's for the humans who are accountable. If the agent pays a premium for faster delivery, someone needs to be able to say, here's why that was the right call. If the agent delays a payment and the vendor gets angry, someone needs to be able to explain the logic. The audit trail isn't just compliance, it's the interface between the agent and the humans who are still responsible for the outcomes.
The audit trail is the interface.
It's the only way humans can understand what the agent is doing. Without it, the agent is a black box that spends money. With it, the agent is a colleague whose reasoning you can review.
And right now, that interface doesn't exist in any standardized form. Every platform does it differently.
Right. And that's the interoperability problem. If you're a small business using two different agentic payment tools, you've got two different audit trails. If a regulator asks you to produce records, you're stitching together two formats. If a dispute arises, you're trying to reconstruct what happened from logs that don't talk to each other.
So the first standards work is really about making the logs talk to each other.
That's the unglamorous foundation. Before you can govern agentic payments, you have to be able to see them. And right now, visibility is fragmented.
Let me ask you about the liability question, because I think that's where this gets legally interesting. If an agent makes a bad payment, who's on the hook?
I honestly don't know. And I don't think anyone does. The legal frameworks weren't written for this. If a human employee makes a bad payment, the employer is liable. If a software bug makes a bad payment, the software vendor might be liable, depending on the contract. But an agent is somewhere in between. It's not an employee, and it's not exactly a software bug. It's an autonomous system that made a decision. So is the principal liable because they deployed it? Is the platform liable because they built it? Is the payment rail liable because they executed it?
The answer probably depends on the contract, which means it depends on who has the better lawyers.
That's the current state. The contracts will allocate liability until the law catches up. And small businesses are at a disadvantage in those negotiations. If a large platform says, you accept all liability for agent decisions, the small business either accepts or doesn't use the platform. There's no negotiation.
So the governance standards, when they come, are also about protecting the smaller players from liability dumping.
Potentially. If the standard says, here's the minimum audit trail required for an agentic payment, and here's how liability is allocated based on the audit trail, then everyone knows the rules. Without that, it's the wild west, and the wild west favors the people with the most lawyers.
Which is not the small business.
No. It never is.
Hilbert: I had a compliance job once. Nineteen ninety-eight. Online payments startup. We were building an automated payment system for affiliate marketers. Agents before agents. A Perl script that approved transactions based on rules. We had a spreadsheet and a fax machine. That was the audit trail.
A fax machine.
Hilbert: The script authorized a payment to a vendor that didn't exist. Fourteen hundred dollars. Nobody could figure out who approved it. The log said the script followed the rules. The rules said the vendor was in the database. The database said the vendor was verified. Nobody could say who verified it. The spreadsheet had a note. The note said, looks fine.
So the audit trail existed, it just didn't answer the question.
Hilbert: That's the thing. Everyone thinks the problem is having no records. The problem is having records that don't mean anything. We had records. We had a lot of records. We couldn't use them to figure out who was responsible. The CEO eventually said, from now on, a human signs off on every transaction. So we had a human whose job was to look at the script's output and click approve. Rubber stamp. Fourteen hundred dollars became a lesson in why you don't let a Perl script spend money.
Did the rubber stamp help?
Hilbert: It made the CEO feel better. Didn't make the system safer. The human didn't understand the rules any better than the script did. He just clicked approve. But now there was a name on the approval. So when the next bad payment happened, there was someone to blame.
That's the messy middle. Human oversight that doesn't actually oversee anything. It just creates the appearance of accountability.
Hilbert: The standard won't fix that. The standard will say, you need human oversight. It won't say, the human has to understand what they're overseeing. That's the part that gets missed.
So the rubber stamp is a stopgap that becomes permanent because it satisfies the requirement without doing the work.
Hilbert: And it costs money. We paid a guy forty thousand a year to click approve. That was the compliance budget. A guy with a mouse.
The question is whether we're going to repeat that with agentic payments. Whether human oversight becomes a real check on the agent's decisions, or just a procedural step that makes everyone feel better.
Hilbert: In my experience, it's the second one. The human doesn't have time to review every transaction. The agent makes a hundred decisions an hour. The human can maybe look at five. So they look at the five that are flagged. The rest go through. That's not oversight. That's sampling.
The sampling gives you a false sense of security, because the ninety-five you didn't review might be the ones with problems.
Hilbert: That's what happened to us. The bad payment wasn't flagged. It went through the same as all the others. The human clicked approve on a screen full of transactions and never noticed. Because why would he? The script said it was fine.
The real challenge isn't writing the standard. It's designing oversight that actually works when the volume of decisions exceeds human capacity.
Hilbert: You can't review what you can't see. And you can't see a hundred decisions an hour. So either you slow the agent down, which defeats the purpose, or you accept that some decisions won't be reviewed, which means some bad ones will get through. There's no third option.
Unless the agent reviews itself. Build the oversight into the system. The agent logs its reasoning, flags its own uncertain decisions, and the human only looks at the uncertain ones.
That's the real-time risk assessment model. The agent doesn't just execute, it evaluates its own confidence. If it's confident, it proceeds. If it's uncertain, it escalates. The human becomes an exception handler, not a rubber stamp.
Hilbert: That's what we should have built. Instead we built a script and a guy with a mouse.
The script and the guy with the mouse is the cautionary tale. It's what happens when you bolt oversight onto a system that wasn't designed for it.
It's what the standards need to prevent. If ISO 42001 or whatever comes next just says, have human oversight, without specifying what that means, you get the rubber stamp. You get compliance theater. You get a guy with a mouse.
Hilbert: Forty thousand a year. Plus benefits.
The benefits were the real cost.
Hilbert: They always are.
Where does that leave us? We've got one thread that's about certifying AI management systems, and the standard doesn't quite cover agents yet. And we've got another thread about agentic payments, where there's no standard at all. And in both cases, the small business is the one that has to make it work.
The small business is the test subject. They get the compliance burden before the compliance clarity.
The question Daniel's really asking is, what do you do when you're the test subject? Do you wait for clarity, or do you build the bones of governance now and hope you guessed right?
I think you build the bones. Not because you know what the standard will require, but because the habits are the same regardless. Document what your agents do. Keep a decision log. Think about risk. Those are useful even if no standard ever arrives. They make your product better.
They make you ready. When the checkbox appears, you're not starting from zero. You've got the raw material for certification. You've got the audit trail. You've got the risk assessments. You're ahead of the people who waited.
The people who waited will be scrambling to build a compliance program from scratch while also trying to keep their clients happy. That's a hard position to be in.
It's going to happen to a lot of them. The ISO 27001 pattern suggests that once the checkbox appears, it spreads fast. The first year, it's aspirational. The second year, it's conditional. The third year, it's mandatory. Small businesses that wait until the third year are in trouble.
The advice, if Daniel's asking for advice, is start now. Not with full certification, but with the habits that make certification possible.
On the payments side, pay attention to the working groups. Watch what the platforms are doing. If you're using agentic payments, ask your vendor about their audit trail. Ask what happens when something goes wrong. Ask who's liable. The answers might be vague, but asking the questions now means you're not surprised later.
The open question is whether the standards will come from industry consortia or regulators. And whether small businesses will have any voice in the process. I suspect the answer is no on the voice, and industry consortia on the standards. Which means the standards will be written by the platforms for the platforms.
But there's a counterweight. Regulators like MAS are watching. If the industry standards don't protect the smaller players, regulators might step in and impose something. That's the threat that keeps the consortia honest. They'd rather write the rules themselves than have rules written for them.
The next few years are a negotiation. The platforms want self-regulation. The regulators want oversight. The small businesses want clarity. And the technology keeps moving faster than any of them can respond.
That's the thing about agentic payments. By the time we've defined the standards, the technology will have moved on. The agents will be doing things we didn't anticipate. The standards will be chasing the technology, the same way they always have.
But that's not a reason to give up on standards. It's a reason to make them flexible. Principles-based rather than prescriptive. The MAS approach, not the Perl script approach.
Right. The goal isn't to freeze the technology. It's to create a framework that can adapt as the technology changes. That's what ISO 42001 is trying to do, imperfectly. That's what the agentic payments standards will need to do, eventually.
The small business that survives this transition will be the one that treated compliance as an investment, not a tax. The one that built the habits early, that documented their work, that asked the hard questions about liability and oversight. They'll be the ones with a seat at the table, even if it's a small seat.
The ones who waited will be outside the room, hoping the rules don't crush them.
That's a hard place to be.
It always is.
I think the most interesting question isn't what the standards will be. It's who gets to define them. Because whoever defines the standard defines the market. And right now, the room where those definitions are being written doesn't have many small businesses in it.
That's the thing to watch. Not the standard itself, but the room where it's being written. The names on the working group roster. The companies funding the consortia. That tells you more about the future than any draft specification.
If Daniel's small business listeners want to have a voice, they need to find their way into those rooms. Through trade associations, through vendor councils, through whatever channels exist. It's not impossible. It's just hard.
It's the same work as any other kind of advocacy. Show up, build relationships, make your case. The standards won't be written by the people who care the most. They'll be written by the people who show up.
That's a good note to end on. Show up.
Show up, and document your agents.
Don't hire a guy with a mouse.
Thanks to our producer Hilbert Flumingtop for keeping us on the rails.
This has been My Weird Prompts. If you want to reach us, email the show at show at my weird prompts dot com.
We'll be back soon.
