Strategy on AI Strategy Paper

B1. Vision and Strategic Embedding

Mon, 01 Jan 0001 00:00:00 +0000

Adopting AI is not an isolated IT project but a strategic decision of executive management. Vision and mission set the frame: AI supports existing goals such as customer centricity, operational excellence, or sustainable value creation. What matters is deciding early where AI contributes directly and where investment is deliberately withheld, in order to focus resources.

What this chapter delivers: six commitments that executive management makes before operational work begins. Decided here, implemented in the chapters of the right-hand table column. Each decision is recorded in the commitment record at the end of the chapter. Without these specifications, operational work gets planned past the corporate strategy.

B2. Identifying and Prioritizing Use Cases

Mon, 01 Jan 0001 00:00:00 +0000

Whether an AI program creates value is decided less by the technology than by selection: use cases get launched that are technically impressive but create little value, or there’s no traceable sequencing.

What this chapter delivers: an end-to-end method from idea generation through evaluation and prioritization to the business case, including templates for direct use. The search space is bounded by the focus fields from chapter B1: searching and evaluating happens primarily where executive management wants to invest. The results feed into the Portfolio Board (see chapter B7) and into the roadmap (chapter C2).

B3. Build, Buy, or Partner

Mon, 01 Jan 0001 00:00:00 +0000

The sourcing path for a use case, that is, building it yourself, buying a standard product, or implementing it with a partner, determines speed, cost, dependency, and data sovereignty.

What this chapter delivers: the decision-criteria matrix for choosing the sourcing path and the vendor questionnaire with eleven categories for structured selection. The frame is set by the policy decision from chapter B1 on whether competencies are built internally or bought; here it becomes concrete for each use case. To that end, the quick rule from chapter B2 (build differentiation yourself, buy standard functionality, bridge gaps with partners) is expanded into a robust decision.

B4. Data Strategy

Mon, 01 Jan 0001 00:00:00 +0000

Every AI strategy is only as good as the data it is built on.

What this chapter delivers: the strategic foundation of data work: which data must be available and where it comes from (data-source inventory, sourcing and labeling), how its quality is assured (six quality dimensions), who decides over it (data governance), and what the knowledge bases of generative use cases additionally need. The data layer of the architecture (see chapter B5) describes the associated technical building blocks.

B5. Target Architecture for AI

Mon, 01 Jan 0001 00:00:00 +0000

A target picture for the AI architecture creates a shared understanding of how data, models, platforms, and processes work together. Without a reference picture, silo solutions, duplicated effort, and security gaps emerge. The architecture shows the necessary building blocks, their connections, and the governing principles, and sets security and data-protection guardrails. It is the basis for technical decisions, budget allocation, and prioritization.

What this chapter delivers: the answer to the question of which technical building blocks a company needs so that AI use cases do not emerge as silo solutions, and how those building blocks relate to each other. The reader (typically a CTO or architect) uses the reference building blocks as a target list: for each block, the architecture inventory records whether it exists in your company, is being built, or is deliberately not needed. The result is your own target picture including a gap list for the roadmap (chapter C2). Per use case, the architecture decision checklist makes the choices concrete. The chapter deliberately prescribes no products: it describes building blocks and principles; product and vendor selection follows in chapter B3.

B6. Operating Model and Organization

Mon, 01 Jan 0001 00:00:00 +0000

While the architecture defines which technical building blocks are needed, the operating model answers who develops, operates, and is accountable for them, and whether AI is steered centrally or distributed across business units. The input comes from chapter B1: there, executive management assigned overall accountability; here, the organization beneath it is designed. Without a clear operating model, uncoordinated initiatives, duplicated effort, and a lack of scalability follow. The goal is a repeatable, scalable, and secure approach across the entire lifecycle, from idea to decommissioning.

B7. Roles and Responsibilities for AI in the Enterprise

Mon, 01 Jan 0001 00:00:00 +0000

AI only has a lasting impact when it is clear who is responsible for what, across the entire lifecycle from strategy and idea intake through development and operations to optimization and decommissioning.

What this chapter delivers: roles, decision rights, and the associated templates (RACI matrix, role profiles) bundled in one place. Chapter B6 sets the organizational form; here the roles within it become concrete.

Principles for role distribution

A role has a clear goal, measurable outcomes, and defined decisions.
Tasks are distributed along the lifecycle: intake, design, development, review, approval, operations, monitoring, improvement, decommissioning.
Responsibilities are separated: whoever develops does not review their own work; whoever approves is independent.
Central guardrails, decentralized delivery: central teams secure standards and building blocks, business units deliver products and impact.
Every role has a backup, handovers, and documented ways of working.

Roles along the lifecycle

The following role map shows all of the chapter’s roles at a glance, grouped into the four sections that follow in detail. Important: the map describes functions, not positions; how roles are bundled depending on company size is covered in the scaling section at the end of the chapter.

B8. Regulation and Compliance

Mon, 01 Jan 0001 00:00:00 +0000

Regulation is not a side issue for AI but a design variable of the strategy. The EU AI Act (Regulation 2024/1689) is the world’s first comprehensive AI law and applies extraterritorially: any company that develops, places on the market, or deploys AI systems is covered, provided people in the EU are affected, regardless of where the company is headquartered.

What this chapter delivers: a framing of the obligations, a decision tree for risk classification, the high-risk obligations in detail, and the interlocking with the GDPR, sector supervision, and German labor law. It does not replace legal advice; binding assessments are made together with legal and compliance functions.

B9. Security for AI

Mon, 01 Jan 0001 00:00:00 +0000

AI systems expand a company’s attack surface with new, specific threats that classic IT security does not cover. Anyone deploying models, and agents in particular, gives these systems access to data and, in part, to actions; accordingly, dedicated protective measures are needed.

What this chapter delivers: the threat landscape along the OWASP Top 10 for LLM applications, mapped to typical application types, plus a protection architecture, a testing approach, incident response, and a ready-to-use security checklist. It complements the security layer from chapter B5 and operationalizes the cybersecurity requirements of the EU AI Act (see chapter B8).

B10. Ethics and Responsible AI

Mon, 01 Jan 0001 00:00:00 +0000

Regulation defines what is legally required (see chapter B8); ethics and responsible AI define what the company additionally considers right, even where the law is silent.

What this chapter delivers: the guardrails for fairness, transparency, and human oversight that already appear as principles in other chapters, bundled and made verifiable: with metrics, methods, a review process, and templates. The reference frameworks are the EU Ethics Guidelines for Trustworthy AI, ISO/IEC 42001 (AI management system), and the NIST AI Risk Management Framework; see chapter E2 for source references.

B11. Change Management and Enablement

Mon, 01 Jan 0001 00:00:00 +0000

AI projects rarely fail because of technology and often fail because of people: a lack of leadership, low acceptance, unclear communication, or missing skills. Change management and enablement are therefore not a side issue but an integral part of the strategy, with their own roadmap and measurable outcomes.

What this chapter delivers: the concrete program for the mandate and budget from chapter B1. A change succeeds when seven questions are answered: who carries it, whom it affects, how people move through it, how they stay informed and involved, whether they can work with AI, whether it all works, and how it lasts. The sections follow this logic: