Strategy before technology
Before choosing tools, decide what you’re trying to win at — and what data you’ll need to make that strategy real.
Goal of this module: help decision-makers choose data direction before choosing tools. Strategy answers “what are we trying to win at?” Technology answers “how do we implement it?”.
Most AI programs stall when they start with tooling (“we need a lakehouse”, “we need high-end GPUs”) rather than a clear intent with measurable outcome.
The Action: Decided they needed a "Vector Database" and an "LLM Orchestration Platform" because these were the trending technologies — €50,000 on licenses and three months of engineering time for a complex RAG system.
The Result: Their customers didn't want to "chat" with documents; they simply needed a faster way to export data into Excel. The system was eventually scrapped for a simple keyword-search tool.
The Action: Started with a bottleneck — 12 minutes for a human to find a clause in a 200-page regulation — and defined the strategy as "reduce retrieval time to under 30 seconds".
The Result: Skipped the expensive "AI platforms" and met the target with a lightweight indexing tool and a cloud OCR service — for less than €5,000. They didn't buy an "AI Tool"; they engineered a "Retrieval Outcome".
A "Tool-First" approach starts with a solution and searches for a problem. A "Strategy-First" approach starts with a technical bottleneck and selects the minimum viable technology to break it.
Deep Dive: 3 questions that prevent expensive detours
An "expensive detour" often occurs when an organization commits to a complex architectural pattern — like a Data Lakehouse or a Real-time Inference Pipeline — before defining the technical task. The three questions below act as technical filters to ensure your strategy dictates your stack.
1. The Decision Anchor: What specific automated action is the architecture driving?
Data engineering often falls into the trap of building "data graveyards" — huge
repositories of data with no clear exit point. A strategy-first approach requires you to
define the Decision Anchor: for a startup building a recommendation
engine, the anchor is a real-time API call; for a public office auditing tax filings,
it is a batch-processed report.
The Detour: Building a high-latency Data Lake when your technical
intent requires low-latency, real-time responses.
2. Infrastructure Gravity: Does the proposed tool align with where the data "lives"?
Technically, this is about Data Locality. If your primary data resides
in legacy on-premise servers (common in public administration), choosing a cloud-native
tool that requires high-bandwidth data egress will lead to massive hidden costs and
latency issues.
The Detour: Selecting a "best-in-class" AI tool that is
incompatible with your data residency requirements or compliance guardrails (like
GDPR-restricted regions).
3. The "Vanilla" Benchmark: Can we solve the technical task with existing services?
SMEs often over-engineer by trying to build custom ML platforms. Before adopting
specialized tooling, benchmark against "Vanilla" services (standard SQL databases or
basic cloud APIs).
The Detour: Spending six months setting up Kubeflow or a
Feature Store when a simple automated Python script and a managed SQL instance
would have achieved the same technical outcome.
Technical detours aren't caused by "bad tools," but by "wrong fit." Force your technical teams to present the Decision Anchor first. If they cannot describe the final action the data triggers, you are about to buy a tool you don't need.
Define your “AI intent”
In this section you connect your AI goal (“intent”) to the kind of data focus you need (coverage, feedback loops, auditability, speed).
In the world of AI, there is a dangerous gap between what a manager says and what an engineer builds. Closing this gap is the essence of defining "Intent" — the strategic bridge that ensures technology serves the mission, not the other way around.
In practice, intent means being able to point to a specific bottleneck and saying: "We will apply a statistical model here to change this specific outcome."
"We want to use AI to become more efficient and innovative."
No problem, no metric, no owner — engineering can't tell when it is "done".
"Cut invoice handling time 40% by auto-extracting fields from supplier PDFs; humans review low-confidence cases."
Clear value, measurable, scoped to data you already have.
Intent is the contract between the business lead and the technical team — specific enough that you can actually evaluate "done".
Picking battles you can win. For SMEs, intent is about picking battles you can win — a common mistake is choosing a high-value intent that is technically impossible for your current data maturity. Look for intents where you already have "exhaust data" (data generated automatically by your current processes) and where the business impact is clear. The matrix below helps you prioritize:
Deep Dive: What "intent" means in practice
1. The Interest vs. The Task
Every AI project begins with a Business Interest, but it only succeeds when it is refined into a Data Task.
- The Interest (Vague): "We want to improve citizen satisfaction with our digital services." (This is a goal, but it has no technical intent).
- The Task (Specific): "We intend to reduce the average wait time for building permit responses from 15 days to 5 days by using an LLM to pre-check applications for missing documentation."
Strategic intent is not a "set-and-forget" memo: you might start with the intent to "Automate Sales Emails" but realize through testing that your real problem is "Lead Qualification". A mature leader allows the intent to evolve based on what the data reveals.
2. The "Four Pillars of Intent" for Decision Makers
To define intent for your organization, answer four questions before a single line of code is written:
- What is the Prediction? What exactly are we trying to guess? (e.g., Which part will break? Which invoice is fraudulent?)
- What is the Action? If the AI gives us a 90% accurate prediction, what will we actually do with that information? If you don't have a plan to act on the prediction, the AI has no value.
- What is the Metric? How will we know it's working? This should be a business metric (money saved, lives improved), not just a technical metric (accuracy, F1 score).
- What is the Constraint? Are there legal, ethical, or budget boundaries? Especially in public administration, the "intent" must include fairness and transparency as a primary requirement.
If your AI project plan contains any of the following phrases, your "Intent" is too vague:
- "Leveraging our data assets..."
- "Becoming an AI-first organization..."
- "Enhancing the user experience with magic..."
Replace these with: "Reducing [X] cost by [Y]% through the automation of [Z] task."
Intent is the "Contract" between the business lead and the technical team. Your job as a manager is to guard the Problem Space while the engineers guard the Solution Space. Do not let the technology dictate the problem. If you cannot explain the "Intent" of your AI project to a non-technical staff member in two sentences, you are not ready to start building.
Deep Dive: Checklist for translating intent to data requirements
Once you have identified your Decision Anchor, translate that strategic goal into a technical specification:
1. Define the Machine Learning Task
Your intent must be mapped to a standard machine learning task. This determines the structure of the data you need to collect:
- Classification: Categorizing data (e.g., "Is this invoice approved or fraudulent?").
- Regression: Predicting a continuous value (e.g., "What will the temperature of this machine be in two hours?").
- Named Entity Recognition (NER): Identifying specific information within text (e.g., "Extract names and dates from these building permits").
2. Inventory Your "Exhaust Data"
BBefore buying new data or building complex scrapers use inventory data or "Exhaust Data"—data automatically generated by your existing business processes:
- Application Logs: User interactions, timestamps, and error rates.
- Transaction Records: Historical sales, citizen requests, or inventory shifts.
- Environmental Data: Sensor readings or time-stamped metadata already living in your databases.
3. Map the Technical Schema
The schema is the blueprint that turns raw data into intelligence. Ensure your requirements define:
- Labels: The "ground truth" the AI needs to learn (e.g., "damaged" vs "not damaged").
- Attributes: Specific properties relevant to the decision (e.g., "color," "weight," or "urgency level").
- Spatial/Temporal Context: Where and when the data was captured, which is critical for preventing "silent failures" caused by context gaps.
4. Determine Latency and "Freshness" Needs
Does the decision anchor require the AI to react in seconds or can it wait for a weekly report?
- Batch Processing: High volume, processed at intervals (e.g., monthly budget forecasting).
- Streaming/Real-time: Low latency, processed as it arrives (e.g., immediate fraud alerts or sensor-based safety stops).
A technical requirement is only valid if it supports the Intent. If you require real-time processing (high cost) for a decision that only happens once a month (low frequency), your strategy has drifted into an expensive detour. Use this checklist to prune your requirements back to the Minimum Viable Data needed to hit your Decision Anchor.
Interactive task: Pick the statement that best describes your main reason for using AI. You’ll get a suggested data focus.
The Logic of Winning: cost engine vs revenue generator
A simple strategic lens: is your AI mainly a cost engine (efficiency) or a revenue generator (differentiation) — and what data focus follows from that?
A "Cost Engine" strategy focuses on internal optimization: reducing manual labor, cutting waste, and speeding up existing workflows. In public administration and SMEs, this is often the starting point — but these teams frequently fall into the trap of treating AI as a standard IT upgrade: in standard software, a rule-based system is robust; in AI, automation is probabilistic.
A "Revenue Generator" strategy uses AI to create differentiated value — features your competitors don't have, or personalization that drives growth. The trap here: features built on generic APIs are easy to copy — if your competitor can plug in the same API tomorrow, you have no Strategic Moat. Differentiation needs proprietary signals.
Deep Dive: What "cost engine" teams often underestimate
1. The "Fragility of Automation"
"Cost Engine" teams often underestimate Process Variance. If you automate a document-checking process that has 5% "edge cases" (unusual documents), the AI may confidently misprocess those cases. Without a high-fidelity "Human-in-the-loop" (HITL) architecture, the cost savings of automation are often wiped out by the cost of auditing and fixing silent AI errors.
2. Change Management and Skill Gaps
If an AI tool saves an employee 2 hours a day, but the organizational strategy hasn't defined what that employee should do with those 2 hours, the ROI is effectively zero. Teams often underestimate the Psychological Barrier: staff may sabotage a cost-saving AI if they perceive it as a threat to their job security.
A "Cost Engine" is not a "set-and-forget" project. To succeed, you must move from a Project Mindset to a Product Mindset. Budget at least 50% of your resources for "Day 2" operations: monitoring for accuracy drift, managing cloud costs, and retraining staff to work alongside the AI. The goal isn't just to automate a task, but to engineer a more resilient, scalable process. Watch the two costs from Module 1's cost iceberg in particular: the "Inference Meter" (usage-based Opex) and the "Silent Tax" (integration & maintenance debt).
Deep Dive: What "revenue generator" teams often underestimate
1. The "Commodity Trap"
Many teams underestimate how easy it is for competitors to copy "Revenue Generating" features built on generic APIs. If your value proposition is a "Chatbot for X," and your competitor can plug in the same OpenAI API tomorrow, you have no Strategic Moat. Prioritize Proprietary Signals: data that only your company has access to, which makes your version of the AI uniquely better over time.
2. The Complexity of the Feedback Loop
To differentiate, your AI must learn from user behavior. This requires a Feedback Loop architecture — teams often underestimate the engineering effort required to capture "Implicit Feedback" (e.g., a user didn't click the AI suggestion) and feed it back into the training cycle. Without this loop, your product remains static while user expectations evolve.
3. The "Vibe Check" vs. Systematic Evaluation
In startups, teams often rely on "Vibe Checks" — the AI looks like it's working well during a demo. For customer-facing features you need Rigorous Evaluation Frameworks and a "Ground Truth" dataset to test against before every deployment, to ensure a new update doesn't accidentally offend or mislead a customer.
4. Scalability and Latency Barriers
An internal "Cost Engine" can be slow, but a "Revenue Generator" (like a product recommendation engine) must be fast. Teams often underestimate the Latency-Cost Trade-off: delivering a "smart" response in under 200ms is significantly more expensive and architecturally demanding than a batch process that runs overnight. If your AI is too slow, users will abandon the feature, regardless of how "smart" it is.
Competitive advantage in AI comes from Proprietary Context, not model size. Focus your team on capturing unique data points from your customers that no one else can see. Ensure your roadmap prioritizes the Feedback Loop from day one. In a "Revenue Generator" strategy, your AI is not a tool; it is a living part of your customer experience that must adapt faster than the market.
Interactive task: Choose the option that best matches your current strategy. You’ll get a recommended data focus.
Build vs Buy decision simulator
In this section you decide what to build vs buy. The goal is to protect focus (what differentiates you) while managing cost, risk, and sovereignty.
Build vs Buy is not an ideology. Module 1's matrix told you when to build, buy or partner — this section is about what that choice does to your independence: lock-in, sovereignty, and your exit plan.
Sovereignty is often misunderstood as simply "owning the servers." For a modern organization, Digital Sovereignty is actually about Portability and Agency: the ability to move your logic, your data, and your users without a catastrophic business interruption.
The "Buy Fast" decision: A professional-services startup needed an AI-powered system to analyze legal contracts. To launch in weeks rather than months, they "bought" a niche SaaS (Software as a Service) AI platform designed for legal teams. The setup was instant, the "vibe check" was positive, and the monthly subscription was a manageable €2,000.
The "Customization Cliff": Six months later, their strategy evolved — they needed the AI to connect to their custom billing software to automatically trigger invoices. The "Buy" solution was a closed system with no API for the data they needed: getting it out cost €15,000 in "Custom Engineering" plus a permanent increase in their subscription tier.
The hidden "Egress" costs: As their volume grew, the vendor charged per document processed — €2,000/month ballooned to €12,000/month. And because all their historical "Labels" (the human intelligence they had added) were trapped in the vendor's database, moving to a cheaper alternative would have required 400 man-hours of re-labeling.
The lesson: They eventually had to "build" their own orchestration layer anyway — they had originally "bought" the Problem Space instead of just a Technical Capability.
| Phase | Expected Cost | Actual TCO (Total Cost of Ownership) |
|---|---|---|
| Launch | €2k / mo | €2k / mo (Success) |
| Integration | €0 (Included) | €15k (One-time "Customization Fee") |
| Scaling | €5k / mo | €12k / mo (Usage & Egress Tax) |
Expected cost vs. actual total cost of ownership (TCO) — integration and egress fees are where "buy fast" gets expensive.
"Buying fast" is a valid strategy to prove a concept, but it becomes expensive when you mistake a Feature for a Platform. Before buying, apply the "80/20 Customization Rule": If you suspect you will need to customize more than 20% of the vendor's standard workflow, the "Buy" solution will eventually cost you more in workarounds and "lock-in tax" than a modular "Hybrid" build would have cost from day one.
Deep Dive: What "vendor lock-in vs sovereignty" really means
1. The Three Layers of Lock-in
Lock-in is rarely a single event; it happens across three technical layers:
- Data Lock-in: The vendor stores your data in a proprietary format
or makes "egress" (taking your data out) so expensive that you are financially
trapped.
The Strategy: Prioritize tools that support "Open Table Formats" (like Iceberg or Delta) so your data remains accessible to other tools. - Logic/API Lock-in: You write thousands of lines of code to talk
specifically to one vendor's AI "brain." If they change their model or pricing,
your code becomes useless.
The Strategy: Use "Orchestration Layers" (like LangChain or standard API wrappers) that allow you to swap the underlying model with minimal code changes. - Skillset Lock-in: Your team becomes experts in a specific vendor's
niche language rather than industry-standard Python or SQL.
The Strategy: Follow the "Vanilla Benchmark" — if a tool requires highly specialized, non-transferable skills, it is a high-risk sovereignty choice.
2. The "Exit Plan" as a Decision Anchor
A mature strategy requires an "Exit Plan" before the "Purchase Order." If the vendor doubled their price tomorrow, how long would it take your team to migrate to a competitor? If the answer is "more than 6 months," you have surrendered your sovereignty.
Sovereignty is the price of Optionality. You "Buy" to move fast, but you "Architect" to stay free. Protect your Decision Anchor by ensuring your most valuable asset—your proprietary business data—is never stored in a way that requires a specific vendor's permission to access. Build your "Secret Sauce" on open standards, even if the "Brain" you use today is rented.
Interactive task: Answer all questions, then click Get recommendation.
The concept of inversion: How would you guarantee failure?
In this section you turn predictable failure modes into practical guardrails (“anti-requirements”) that keep projects on track.
Strategic inversion asks: "What must we definitely avoid for this project to fail?" For an SME or a public office, failure usually stems from three sources: technical drift, runaway costs, or "Black Box" dependency.
Guardrails are the Anti-Requirements — hard technical or process boundaries that trigger an immediate stop if crossed.
A regional public-administration office was implementing an AI system to assist in the initial screening of grant applications for small businesses.
The potential failure mode: During the "Inversion" workshop, the team asked: "How could this fail so badly we end up in the news?" The answer: the AI might develop a "Hidden Bias" — for example, accidentally favoring applicants from certain postal codes, because the historical data used for training contained those biases. If that happened, they would have to manually re-review 5,000 applications, costing months of labor and legal fees.
The guardrail: Instead of just "trying to be fair," the technical lead implemented a Statistical Guardrail called "Parity Monitoring" — with a hard stop: if the AI's approval rate for any postal code drifted more than 10% away from the reference average, the system would automatically lock, stop processing, and notify the Governance Board.
The moment of truth: Two months into production, the guardrail triggered. A recent change in the digital application form had made it harder for people using mobile phones to upload a specific document — the AI was interpreting "Missing Document" as "Low Quality Business", which disproportionately affected younger entrepreneurs applying via mobile. They fixed the form, retrained the model on the corrected data, and resumed.
Bias discovered 6 months later by an external audit or citizen complaint — high legal fees, political fallout, total project restart.
Bias discovered in 48 hours by an internal automated check — 40 applications affected instead of 4,000, two days of engineering to fix the form. Estimated saving: four months of corrective work, and no public scandal over "Algorithmic Discrimination".
A guardrail is the only way to manage the Probabilistic Risk of AI. You cannot prevent every error, but you can build a system that "fails fast and fails safely." In SMEs and public admin, the "Safety Gate" is more important than the "Accuracy Score." If your technical team says "Trust the model," respond with: "I trust the guardrail".
Deep Dive: How to use guardrails in real projects
1. The "Data Freshness" Guardrail
The Failure: Making decisions based on a reality that no longer exists
— a model trained on last year's shipping prices gives "correct" answers to an
"incorrect" world.
The Guardrail: If the input data has not been updated within your
Decision-Anchor interval (e.g. 24 hours), the AI system automatically disables itself
and alerts a human.
2. The "Confidence Threshold" Guardrail
The Failure: The AI "hallucinates" or guesses on a high-stakes decision
— in public administration, an AI incorrectly flagging a citizen for an audit is a
catastrophic loss of trust.
The Guardrail: Never allow the AI to have the final word on
low-confidence predictions. Program the system with aThreshold Gate:
If the model's confidence is below 90–95%, the decision is automatically routed to
a human queue. The AI handles the "easy 80%", humans handle the complex edge cases.
3. The "Usage & Unit Economics" Guardrail
The Failure: A "Revenue Generator" that costs more to run than it
earns.
The Guardrail: Implement API Cost Quotas at the
architecture level. If the inference cost per user session exceeds a specific Euro
amount, the system reverts to a "Vanilla" (non-AI) version — protecting you from a
"success disaster" where a viral feature bankrupts the company.
4. The "Single Point of Failure" Guardrail
The Failure: Only one external contractor or one internal developer
knows how the system works.
The Guardrail: A "No-Custom-Silo" rule. Every AI pipeline must be
documented in your standard Technical Schema and use "Vanilla"
cloud-native services. If a project requires a tool no one else can even log into, it
is paused until a "Bridge" person is upskilled.
Guardrails are not "policing"; they are Risk Automation. As a manager, your job is to define the "Kill Switches." Identify the three things that would make you cancel the project (e.g., accuracy below X%, cost above Y, or data older than Z) and have your technical team build those limits directly into the software. A project with guardrails is a project that can be trusted to run while you sleep.
Interactive task: Select the failure modes you want to avoid, then click Generate guardrails.
Key takeaways
A short summary of module 2.
- Intent comes first: define what you're trying to win at.
- Translate intent to data requirements before choosing tools.
- Name the logic of winning: is each project a cost engine (efficiency, lower risk) or a revenue generator (differentiation through proprietary signals)?
- Build vs buy is strategic: build differentiators, buy commodities, combine when needed — and protect sovereignty with open formats and an exit plan.
- Use guardrails: define what "failure" looks like and prevent it by design.
- Your strategy is effectively a set of "No's" that protect your limited resources from "Tool-First" detours.
- AI should not be an "IT Project" — it is a Data Product, delivered by a "Data Translator" who bridges the shop floor and the code.
Your goal is to build an AI-Capable Organization, not just an AI project. This requires Strategic Inversion: protecting the business from the "fragility" of AI through guardrails, while maintaining sovereignty through open technical standards.
The Strategic Filter — for every item on your AI roadmap, ask:
- Is this a Low-Hanging Fruit (High Impact/High Feasibility)?
- Does it align with our North Star?
- Can we solve this with a "Vanilla" Benchmark tool?
If an item fails these three, it is a detour. Prune it.