These Are Not the Droids You Are Looking For

I keep seeing LinkedIn posts that portray a clean data model as the pillar AI must be built on.

That is false.

A perfect, centralized, human-designed data model is not the prerequisite for AI. Waiting for one is how organizations postpone AI until they have no money, time, or relevance left to catch up.

The advice always sounds responsible: organize the data, settle every definition, clean every source, establish every owner, perfect every domain—and then begin AI.

For many organizations, that is not architecture. It is procrastination wearing the clothes of architecture.

It is the same mindset that passes up a trip to the beach or the mountains because the conditions are not perfect. The weather might change. The hotel may not be ideal. The route might take longer than expected. So the trip never happens.

In business, the equivalent is: “We cannot use AI until our data is perfect.”

At the end of 2026, that is not a strategy for being left behind.

It is a strategy for failure.

Organizations that wait for perfect data will spend their money refining yesterday’s operating model while competitors build systems that learn, improve, and compound their advantage. Eventually, the organization that waited will run out of money, time, or relevance.

This is likely existential.

Companies that get this right will outlive the companies that do not.

Tempus fugit. Time escapes.

Time does not wait while an organization debates the perfect data model, funds another discovery phase, or reorganizes the same information for the third time.

Competitors do not need to have solved every data problem to begin learning faster. They only need to build a governed system that can act, learn, improve, and compound.

Every month spent waiting for perfect conditions is not neutral time. It is time handed to companies that are already building the capability to operate differently.

The danger is not that AI will arrive too quickly.

The danger is that organizations will spend so long preparing for AI that they miss the period in which preparation could have become advantage.

The data model is not the pillar

Human information systems were built around human limitations.

We made folders because people needed folders. We created filing systems because paper had to live somewhere. We built taxonomies because older software could only understand the labels we explicitly assigned. We spent decades making information fit structures because systems could not interpret what the information meant.

That was necessary. It is no longer sufficient.

AI can use semantics, ontology, relationships, metadata, permissions, provenance, and business context to understand information across files, databases, APIs, streams, applications, and conversations. It can identify duplication, connect related concepts, surface stale information, reveal missing context, and help establish the structure that matters going forward.

Data quality, security, governance, ownership, and accountability still matter. They matter more than ever.

But they are not reasons to delay AI. They are requirements for designing AI systems correctly.

The foundation is not a perfect data model.

The foundation is governed access, meaningful context, clear permissions, traceability, evaluation, and human accountability.

Do not wait for humans to optimize data for yesterday’s AI.

Use AI to optimize data for the future.

SharePoint was the filing cabinet

SharePoint is a useful warning.

In many organizations, it became the evolution of a filing cabinet. Stacks of paper became documents. Drawers became folders. Access lists became permissions. Search became somewhat easier.

But digitizing the filing cabinet did not redesign the business system behind it.

The same handoffs remained. The same bottlenecks remained. The same unclear ownership, invisible work, duplicate effort, and dependency on people remembering where something lived remained. The filing cabinet became digital, but the operating model did not become intelligent.

AI must not repeat that pattern.

A chatbot attached to a document repository is not transformation.

A small script attached to an LLM is not transformation.

A bot inserted into one worker’s existing process is not transformation.

Those may be useful tools. But they are not systems.

They are more sophisticated filing cabinets: an easier way to find, summarize, or move the same work through the same broken operating model.

The opportunity is to build systems around outcomes: systems that understand context, connect information, coordinate work, bring people in where judgment and accountability matter, and improve as they operate.

AI should not be designed to replace people.

It should be designed to replace broken system behavior: unnecessary searching, repeated handoffs, disconnected decisions, invisible work, stale assumptions, fragmented information, and process friction.

Stop building bots. Build systems.

Much of today’s AI conversation is still too small.

It focuses on a single employee with a copilot. A personal assistant. A workflow script. A prompt that drafts an email. A bot that makes probabilistic decisions inside one narrow process.

Those tools can be useful. But they are not a business system.

A business system has an outcome. It has inputs, decisions, authority, controls, handoffs, exceptions, feedback, and accountability. It spans people, information, tools, policies, and operational realities.

A real AI system should do the same.

It should observe what is happening across the work. It should understand the information available. It should identify the relevant context. It should coordinate tasks and decisions. It should execute bounded actions through controlled access. It should bring people into the process at the moments where human judgment is necessary. And it should make the system more capable over time.

That is not trying to replace a person with a probabilistic bot.

People define intent. People make consequential judgments. People build trust and relationships. People establish accountability. People decide what a good outcome means.

AI gives those people leverage.

The goal is not fewer people doing the same work.

The goal is a system that no longer requires people to spend their time hunting for information, manually translating context, chasing approvals, re-keying data, coordinating invisible handoffs, and repairing process failures that should never have existed.

IMLAVD: a transporter model for AI systems

The architecture needs to reflect this systems view.

IMLAVD is a practical way to think through the layers:

• Infrastructure provides the secure, scalable environment for compute, connections, and controls.
• Model provides intelligence that is tested, evaluated, and appropriate for the work.
• Logic & Orchestration provides context, semantic understanding, policy, coordination, priorities, and decision paths.
• Access provides the controlled capability to use tools, services, APIs, systems, and execution environments.
• View is where people and agents collaborate, review, question, supervise, and act.
• Data is the living information landscape: files, databases, APIs, streams, third-party data, operational records, and knowledge distributed across the enterprise.

This is not a stack of prerequisites.

It is a transporter.

Information enters from many places. Intelligence interprets relevance and meaning. Logic coordinates the right action. Access executes within controls. People participate where they add judgment, oversight, and accountability. The system produces an outcome—not simply another document, dashboard, prompt, or workflow ticket.

The system does not wait for a perfect enterprise data model before it begins.

It learns where data needs improvement by doing useful work in a governed way.

AI must optimize the whole system

IMLAVD is the IT DNA: Infrastructure, Model, Logic & Orchestration, Access, View, and Data.

But the purpose of AI is not to sit inside one of those layers as another application, chatbot, or model endpoint.

AI must be enabled to optimize all of them.

It should help optimize infrastructure for capacity, resilience, cost, and performance. It should help optimize models for quality, safety, usefulness, and fit. It should help optimize logic and orchestration for decisions, priorities, policies, and flow. It should help optimize access for secure execution and appropriate control. It should help optimize views so people can understand, supervise, and act. And it should help optimize data for meaning, relationships, quality, availability, and reuse.

That is only half of the system.

Every business also has its own DNA: its customers, products, people, operating constraints, economics, risk, commitments, regulations, capabilities, and desired outcomes.

AI must be enabled to optimize the interaction between the IT DNA and the business DNA.

Not according to a generic maturity model. Not according to a consultant’s slide deck. Not according to what is easiest for one team to implement.

According to the constraints and outcomes the business actually chooses.

The constraint may be safety. It may be cash. It may be speed, service, margin, compliance, quality, trust, or capacity. The desired outcome may be growth, survival, resilience, customer experience, or a fundamentally different way of operating.

Those choices belong to people.

AI’s role is to help the organization see the system, reason about tradeoffs, coordinate action, and continuously optimize toward those outcomes within the boundaries people establish.

That is why a perfect data model is such a dangerous false starting point. It mistakes one component of the IT DNA for the entire system—and then treats that component as a gate that must be perfected before intelligence is allowed to help.

AI should not wait beneath the data pillar.

AI should be allowed to optimize the whole system.

The delivery model is failing too

There is a structural problem in how many organizations deliver technology change.

Value IT teams are frequently organized and measured to maintain, support, intake, prioritize, and deliver work cheaply. They are rarely given the mandate, capacity, or leadership model to rethink how the business should operate.

Consultant leaders are brought in to supply the missing language of transformation. They speak about change, operating models, future state, and strategic direction.

But that model fails just as often.

Many consultant-led projects fail because the consultants are not truly redesigning the system. They lead internal value teams through another cycle of meetings, artifacts, roadmaps, and implementation work—or function as more expensive temporary labor.

One side is constrained to maintain the current model. The other may describe a future model without owning the enduring capability to operate it.

The result is familiar: a transformation program ends, the consultants leave, and the organization returns to the same systems, handoffs, priorities, and limitations.

Neither a cheaper delivery model nor a more expensive consultant is an answer to this problem.

AI exposes the weakness.

It creates the possibility for an internal organization to build a capability that can both operate and change the business system. Not by replacing people, and not by launching another consultant-led program, but by embedding intelligence into how work is understood, coordinated, reviewed, and improved.

The question is no longer whether an organization can buy advice about change.

The question is whether it can build systems that continuously improve—with people accountable for direction, judgment, and outcomes.

Start now

Stop asking whether the data model is perfect enough for AI.

Ask whether the organization has identified an outcome important enough to build an intelligent system around it.

Choose one real business constraint. One outcome that matters. One bounded system where people, information, decisions, tools, and controls can be connected.

Then give AI the governed ability to observe, interpret, coordinate, and optimize across the IT DNA and the business DNA.

Do not start with a chatbot.

Do not start with a filing cabinet.

Do not start with another transformation roadmap.

Start by building a system that can learn.

Tempus fugit. Time escapes.

The companies that survive will be the ones that start now.