Who owns the product when AI decides? Insights from Kamil Marczak

The Meeting Where the Design Wasn’t His

Kamil traces the problem back to a specific moment last year, when he was experimenting with AI as much as possible in his design process. He built a prototype for a meeting with a product manager — faster than anything he could have produced before.

Then he sat down to present it.

I came to the meeting and I felt something — I’m presenting a design made by a colleague or someone else. I had a goal which I presented to ChatGPT, or any other tool, and the AI has answered all the questions which could somehow be answered by me during a normal design process. I felt I’m presenting somebody else’s work — mentally I’m not the owner of the decisions which were accepted, approved during that design process. And I didn’t like it. – Kamil Marczak

That discomfort became the starting point for everything he’s tried to figure out since: how to use AI without losing the core role he’s supposed to have. Because without ownership of the decisions, what’s left?

Am I somebody who just pushes prompts and moves output to another person? Not really. – Kamil Marczak

Governance Debt: When “It Depends” Is the Problem

Ask Kamil who’s responsible when an AI-assisted decision goes wrong, and the honest answer is: it’s hard to pin on one person. Not because nobody cares, but because the system itself was never built to acknowledge that someone should own the outcome.

I try to believe that it’s more a problem of a system, actually — because the way we use AI, that process, that system doesn’t acknowledge that there is somebody responsible for something. – Kamil Marczak

He names the pattern directly: if the honest answer to “who’s responsible” is “it depends,” that’s not a gray area — it’s a debt.

If the answer for your question is “it depends,” it means that you have a governance debt. It’s kind of fresh, which many teams try to find a solution for. But if you happen to be in a situation that you have a problem finding an answer for that, it’s a governance debt — and it could lead to big issues, to be honest. – Kamil Marczak

Kamil’s fix sounds almost too simple: between the AI output and its approval, there should be one named person accountable for it.

Assigning one specific person gives that person responsibility and makes their stakes higher. If your name is assigned to something, you’re more careful about whether the sources the AI has used are up to date, whether the prompt was proper to the goal you’re trying to achieve. – Kamil Marczak

Skip that step, he warns, and the cost isn’t just technical. It’s trust — and trust is far harder to rebuild than the debt most teams are used to managing.

It could lead to not only issues regarding law or finance, but also brand, also trust. AI features which are left to itself can lead to issues which could harm the users at the very end. That could lead to a lack of trust in the end, and that’s hard to rebuild in comparison to, for example, technical debt. – Kamil Marczak

Some teams have started calling this second layer accountability debt — governance is the system, accountability is the person standing behind it.

The Blind Spot Between Design and Development

Kamil’s day-to-day makes the seam visible in a very specific way. He works inside the development team, in product trio meetings with the PM and developers, using meeting transcription tools like Fathom. At some point, he had an idea: feed the meeting transcript straight into an AI tool so he wouldn’t have to redo the same work twice.

It didn’t go the way he expected.

What decisions AI takes out of that transcription — that’s the blind spot. AI sometimes loses track of what was happening before because the context is getting too big. Apart from understanding the feedback I gathered in the transcription, somehow it adds up different features, different things which weren’t there before. Sometimes the features which were supposed to be global in the whole product — sometimes AI loses it. – Kamil Marczak

The result: a feature appeared in the design that Kamil hadn’t consciously approved.

I had a situation where I didn’t know that such an occurrence happens, and the developer asked me why that feature is here, why there’s that button. That’s the blind spot. It’s a very small scale, but I can imagine how it could scale into something much bigger. Without a proper review, without proper accountability assigned to, for example, me, that design could go into production and lead to some issues. – Kamil Marczak

What a Decision Log Looks Like When AI Is in the Room

Before AI, a decision log was simple: it recorded decisions made by people. Kamil’s has already changed shape twice.

At the very beginning, that decision log only had decisions made by me, individually — not AI, not the whole team, just me. Later on I discovered that some of the decisions are made by AI, and that’s not always an issue — it’s great to be conscious about what type of decisions are made by AI. So I’ve updated my assistant to collect decisions made by me and made by AI together. – Kamil Marczak

Even with that update, the boundary is still fuzzy. What counts as an AI decision isn’t always obvious, and different logs — his, the developer’s, the PM’s — don’t always agree on what happened.

It’s still tricky which decisions AI will identify as its decisions, because it’s not so obvious. As teams, we are still experimenting. It’s something which might lead to conflicts between different decision logs — they don’t always acknowledge the same situations, they lack different decisions, so it’s hard to connect all of them. – Kamil Marczak

Kamil’s hope is that within the next six months, teams will be able to merge these separate logs into one shared record as they iterate. For now, he sees it as an industry-wide open problem, not just a Boldare one.

I imagine a situation where we iterate on the design and all the decision logs are in the loop to get merged together. I hope in the next half year we will be able to do that. But now I think it requires further experimentation — and I believe that’s the current state of the market, too, not only in development teams. – Kamil Marczak

Five Questions Every C-Suite Should Ask Before an AI Feature Ships

Asked to name one thing a CPO or CTO should change this quarter so AI-assisted design decisions don’t land in code without an owner, Kamil didn’t give one answer — he gave a checklist.

1. What does the AI actually do? The obvious starting point, but still worth stating explicitly rather than assuming everyone agrees.

2. Who is responsible for that AI feature — one specific person?

Thanks to that, the impact on that feature is trackable. It works in iterations, somebody keeps control over what feedback comes back to that feature, and it’s easier for the whole company. – Kamil Marczak

3. What happens if something goes wrong — who do we call?

When there’s an incident, and then we are already thinking about who will be responsible for that — we have a problem. So doing an audit and thinking about who we will call when something bad happens, who will be notified, is another thing. – Kamil Marczak

4. Who is kept on track when things are quiet? Ownership isn’t just for incidents. Someone needs to be watching the feature even when nothing is visibly wrong.

5. Who has the authority to override an AI decision?

For example, in public systems, financial products, it’s really important — such AI tools can decide whether somebody gets a loan, whether somebody can access a social service or not. Somebody could be also responsible for overriding that decision. It’s popular nowadays, thinking about human in the loop. Without that, it’s hard to talk about accountability and governance. – Kamil Marczak

Kamil is careful not to pretend the answer is universal.

Who is responsible at the end depends on the culture, the processes in your company, and the service you provide. It should, of course, be done before the serious failure — but sometimes the first serious failure could be the best way to learn who should be responsible. – Kamil Marczak

Key Takeaways

The model made a decision. That, on its own, is not an accountability structure.

Designing for this means:

• Naming one person responsible for every AI feature that reaches production — not to assign blame, but to make impact trackable and feedback loops real.
• Treating “it depends” as a signal, not an answer. If nobody can say who owns a decision, that’s governance debt accumulating in real time.
• Auditing the blind spots between roles — especially anywhere AI tools synthesize inputs (meeting transcripts, prior decisions, scattered feedback) without a human checking what came out the other side.
• Building decision logs that can actually tell you which choices were made by a person and which by a model — and planning for how those logs will eventually need to merge.
• Defining, before the first AI-assisted decision reaches a user, who has the authority to override the system — especially wherever the stakes involve someone’s access, money, or trust.

We’re still early in figuring out who owns a decision once a model is in the room. The frameworks are being built in real time, inside product trios, one governance debt at a time — before the failure that forces the question, not after.