AI for Product Managers in Regulated Payments: Skills, Roles and How to Learn
AI product management in payments is not prompt engineering. It is deciding which bounded workflow gets a model, what it is allowed to do, who owns it, and how you prove it behaved.
In this essay
An AI product manager in a regulated payments company is a product manager who decides which bounded workflow gets a model, what the model is allowed to do, who owns its behaviour, and how the company proves it behaved. It is not a research role and it is not prompt engineering. Most of the job is the ordinary product job, applied to a component that is probabilistic, and to an environment where a wrong output can move money or breach a rule.
I have put three AI systems into production in payment operations at Simpaisa: retrieval-based merchant integration support, automatic incident escalation, and document extraction for merchant onboarding. This essay is the syllabus I would give a product manager taking on the same work, and the description I use when hiring for it.
What the role owns
The use case decision. Which workflow, and why this one. The best first candidates in payments are bounded, high-volume, low-consequence-per-item tasks with a human already in the loop: answering integration questions from documentation, classifying and routing incidents, extracting fields from onboarding documents. The worst first candidates are the ones that sound most impressive: autonomous fraud decisions, autonomous routing, anything that moves money without a person. I have written the value model we use in value modelling GenAI use cases in fintech.
The scope boundary. What the model may do, what it may only suggest, and what it may never touch. Written down, reviewed by compliance, and enforced in the system rather than in the prompt. Our incident-escalation system classifies and routes; it does not resolve. Our document extraction proposes field values; a person confirms them before onboarding proceeds.
The evaluation. How the company knows the model is behaving: a test set built from real cases, a metric that matters to the workflow (extraction accuracy per field, escalation precision, answer correctness rated by the support team), and a threshold below which the model is switched off. Evaluation is the AI product manager's core artefact, the way the PRD is the core artefact for a conventional feature.
The audit trail. Every model output that influenced an action is logged with its input, its version and the person who acted on it. In a regulated company this is not optional and it is the product manager's job to make sure it exists before launch.
The human owner. Someone whose job includes watching the model's behaviour weekly and who has the authority to switch it off. If the product manager cannot name that person, the system is not ready.
The economics. Model cost per task against the cost of the human task it assists, tracked monthly, because inference costs and usage patterns both drift.
The skills that matter
In the order I test for them:
Product judgment about bounded scope. Can the candidate look at a workflow and identify the part where a model helps and the part where it must not decide? This is the skill that separates AI product managers from people who have used AI tools.
Evaluation design. Can they build a test set from real cases, define a metric the workflow owner would accept, and set a threshold? Most candidates can describe a model; far fewer can describe how they would know it is wrong.
Enough technical literacy to have the conversation: what retrieval is and why it reduces hallucination, what fine-tuning changes and does not, what a token costs, why latency matters for one workflow and not another. Not the mathematics. The trade-offs.
Regulatory and risk fluency. Which decisions the licence or the scheme rules require a person to make. What "explainability" means to a regulator in practice: a logged reason a human can review, not a research paper.
Change management. AI systems change the work of the people around them, and the operations team decides whether the system succeeds. The product manager who launches an extraction tool without the onboarding team's design input gets a tool the onboarding team works around.
The ordinary product skills remain: problem framing, discovery, prioritisation, writing decisions down. AI does not replace them; it makes the cost of skipping them higher.
Roles and responsibilities, by level
An AI product manager owns one or two systems end to end: use case, scope, evaluation, launch, monitoring, economics.
A senior AI product manager owns the portfolio of AI use cases in a domain, the evaluation standards they share, and the governance relationship with risk and compliance.
A head of AI product owns the company's operating model for AI: which decisions may be automated, how systems are approved, how they are monitored, and how the company answers a regulator's question about any of them. At Simpaisa this sat with me as CPO; in a larger company it is a role of its own.
How to learn it
Start with one bounded workflow in your own company where a human already does a repetitive task with documentation or structured inputs. Build the evaluation set first, from thirty real cases, before touching a model. Then build the smallest system that improves the metric, with a person confirming every output. Run it for a month with the workflow owner watching it. Write down what it got wrong and why. That month teaches more than any course.
Read the production accounts, including the production AI use cases in payments and why AI and ML solutions fail in production payments. The failure accounts are more useful than the success ones.
Learn the regulatory position in your market on automated decisions, model risk and record-keeping. It is shorter than people fear and it defines the scope boundary for you.
Do not start with agents that act. Start with systems that suggest, classify and extract, and earn the right to widen the scope with evaluation results.
Career path
AI product management is becoming a specialisation within product rather than a separate ladder: product manager, senior product manager with AI systems in their portfolio, head of product with an AI operating model. The people who move fastest are the ones with production systems they can describe with numbers: what it did, how it was evaluated, what it cost, what went wrong, what they switched off. A portfolio of three such accounts is worth more in an interview than any certificate.
FAQ
What does an AI product manager do? Decides which workflow gets a model, defines what the model may and may not do, designs the evaluation that proves it behaves, ensures the audit trail and human ownership exist, launches it, and tracks its accuracy and cost over time.
What skills does an AI product manager need? Judgment about bounded scope, evaluation design, enough technical literacy to weigh trade-offs, regulatory and risk fluency, change management, and the ordinary product skills of framing, discovery, prioritisation and decision writing.
How do I learn AI product management? Take one bounded, repetitive workflow in your company, build an evaluation set from real cases, ship the smallest system that improves the metric with a human confirming outputs, run it for a month with the workflow owner, and write down what went wrong.
Do AI product managers need to code? No, but they need to understand retrieval, fine-tuning, cost, latency and evaluation well enough to make trade-offs with engineers and to explain the system to a regulator.
What is the difference between an AI product manager and a regular product manager? The same role applied to a probabilistic component in a regulated environment: the AI product manager adds scope boundaries, evaluation, audit trails, a human owner and cost tracking to the ordinary product responsibilities.
Closing thought and further reading
AI product management in payments is not prompt engineering. It is deciding which bounded workflow gets a model, what it is allowed to do, who owns it, and how you prove it behaved.
Building through similar complexity?
Discuss the operating decisions behind the essay, or explore where my experience can help.


