Amal leans back and looks at her notebook. Three pages filled. Plus four whiteboards covered in post-its from the requirements workshop. Somewhere in all of that are the business objects she needs for the new data model. "Diego," she asks, "how long did it used to take you to figure out what actually needed to be modeled after a workshop like this?" Diego smiles. "Back in the day? Sometimes a week."
Today, Amal gets there in a few hours. Not because she reads faster. Because she works differently. With AI – but not in the way most people imagine. For those who don't know Amal and Diego yet: they're fictional characters from the FastChangeCo universe, which I use to illustrate real challenges from my projects and coaching engagements.
In Article 2, we looked at why AI cannot automatically generate complete data models. Today I want to show you what AI can do instead – and what a hybrid workflow looks like that actually delivers.
The key isn't letting AI do everything. The key is deploying AI exactly where it's genuinely strong – and keeping humans in the loop where it truly matters. Sounds simple. It is. But most organizations still don't do it.
Step 1: Record the conversation – don't just take notes
Let's start with something so obvious it almost feels embarrassing to say: record your requirements workshops. Full stop.
I know, I know. You feel like you're catching everything. You're writing, nodding, asking questions. But honestly – how much slips through? How often do you find yourself thinking afterward, "there was something about the customer definition..." and you just can't find it in your notes?
A recording with a subsequent transcript changes the game entirely. Tools like Microsoft Teams, Whisper, or most modern conferencing platforms handle this almost automatically these days. The result: a complete text document of the conversation – raw, unstructured, but complete.
A quick note on privacy: let your participants know upfront that the session will be recorded. This isn't just a legal requirement – it's good practice. In most project contexts, it's a non-issue as long as you're transparent about it.
That transcript is your raw material. And raw material is exactly where AI excels.
Step 2: AI as a business object detector
Now it gets interesting. You take your transcript and hand it to an AI – Claude, ChatGPT, whatever you use – with a clear task: identify all business objects mentioned or implied in the conversation. List them, briefly explain the context in which they appear, and flag any ambiguities or contradictions.
Amal ran this on the FastChangeCo workshop transcript. The result was striking – and instructive. Within minutes, the AI produced a list of 14 potential business objects. Some were obvious: Customer, Product, Order. Others Amal had missed herself, because they'd only come up in passing: Supplier, Service Entry, Escalation Case.
But – and this matters – three of the 14 were wrong. The AI had interpreted "Sales Channel" and "Customer Group" as separate objects, even though the business team uses both terms interchangeably. And "Escalation Case" wasn't a standalone object in this company's context at all – it was a status on a support ticket.
That's exactly the point. AI captures what was said in the conversation. What wasn't spoken, wasn't probed, wasn't clarified – that's missing from the transcript, and therefore missing from the AI's output. That's why Step 2 isn't "AI decides" – it's "AI proposes."
Step 3: Objects, relationships, and templates – AI pre-fills, humans decide
You now have a list of business object candidates. Before jumping straight into templates, it's worth running a second prompt: ask the AI to name the relationships between the identified objects – as a verb. Not "Customer – Product," but "A Customer purchases a Product." This isn't just a stylistic choice; it's conceptual precision. The verb describes the reason two business objects are related in the first place. And that reason is exactly what becomes the relationship in your information model.
Here again, you see where AI delivers and where it stops: it can name what was said in the conversation. Whether "purchases" is actually the right verb for this particular company – or whether it should be "subscribes to," "licenses," or "commissions" – that's a human decision.
Now the Entity Definition Templates come into play. These are structured documents that capture the key fields for each object – name, definition, synonyms, boundaries, examples, exceptions, source systems, and so on. Here too, AI can give you a head start. Feed it the transcript, the identified object, and the template format – and let it pre-fill a first draft. What comes back? Typically 60 to 70 percent usable content. The basic structure is there, the obvious fields are filled, initial examples are in place.
About this series: This is Part 3 of 4 in our series on AI-assisted data modeling. Part 1 examines the fundamental paradox. Part 2 explains why generic automation fails. Part 4 explores how the data modeler's role is evolving.
Want to go deeper?
In our Data Modeling Training, you'll learn how to develop company-specific data models – beyond generic templates and standard schemas.
What's missing? Exactly the 30 to 40 percent that makes the difference. The company-specific definition. The exception only the sales team knows about. The boundary dispute between business and IT that's been going on for years. The things that live between the lines of a transcript – and that only someone who knows the business model can interpret.
But here's the shift: instead of walking into a validation session with an empty template, you now bring a pre-filled draft. That changes the conversation. Domain experts can react immediately: "That's not right," "This is missing," "That example is wrong." Far more efficient than starting from a blank page.
Step 4: Domain validation – where humans remain irreplaceable
Now comes the part no AI can replace. And the part most people underestimate.
Diego sits down with Amal and two business experts from the sales team. The pre-filled templates are on the table. The central question: "Does this hold up – for our company, in our context?"
The discussion kicks off with the object "Customer." The AI had cleanly defined it as: "A natural or legal person who purchases products or services from the company." That's exactly what was said in the conversation – so the AI captured it correctly. The problem? It was never challenged. And so the AI had no way of knowing that FastChangeCo actually has three customer types: the direct customer, the partner customer, and the end customer in a B2B2C model.
Diego asks the question that changes everything: "Which customer do you mean when you say revenue per customer has increased?" Silence. Then the first expert: "Well... it depends..." And just like that, the conversation that belongs in the model is finally happening.
This is the heart of the hybrid approach. Domain knowledge doesn't live in the AI – but it doesn't automatically live in the transcript either. It lives in the heads of the people who work the business model every day. The data modeler's job is to draw that knowledge out through the right questions: in workshops, in conversations, in validation sessions. Once something is in the transcript, AI can recognize and process it. What was never spoken stays invisible – until someone asks the right question.
The data modeler shifts from documentarian to facilitator. Instead of bringing blank forms, they bring a starting point for discussion. Instead of asking foundational questions, they ask the decisive ones.
What remains for humans – and what the outcome looks like
Let me be concrete. What does this workflow actually deliver?
Identifying business objects, which used to take two to three days, now takes half a day. The initial template population, previously an entire afternoon per object, is done in an hour – as a draft. Validation sessions become more efficient because everyone is working from the same starting point. Net result: less time, fewer misunderstandings, better definition quality.
But – and I want to be deliberate about this – the time you save doesn't go toward sitting on the couch. You invest it in better domain work. In more conversations with subject matter experts. In deeper workshops. In an information model that actually fits the company – because you had more time to ask the right questions.
That's the hybrid approach. AI handles the repetitive, the structuring, the initial population. Humans handle the domain judgment, the decisions, the validation. Not because AI is unintelligent – but because domain knowledge only becomes visible through good workshops and the right questions. Drawing it out of people's heads: that is, and will remain, the core competency of the data modeler.
But what does this mean for the role itself? Does the job get easier – or more complex? That's what the next and final article in this series is about.
So long,
Dirk