Decision owner
Every consequential decision has an accountable business role, not only a technical system owner.
AI systems architecture · Vienna & DACH
The AI pilot works. The operating system around it does not.
The demonstration lands well. Then someone asks who owns the decision, who handles the exception, and who can stop the workflow when the evidence is weak. The room no longer has an answer.
An AI Systems Review turns that gap into an inspectable operating architecture. It is not ERP/CRM integration consulting, and it does not sell generic automation.
Decision signals
Authority boundary
The system may recommend, prepare or act; approval, override and stop authority remain explicit.
Evidence path
Input, version, review rationale, exception and final action form a record the operating team can inspect.
The operating problem
A persuasive model can still sit inside an unowned decision
Many AI pilots fail their first operational test before the model fails. A non-standard case arrives, the output looks plausible, and responsibility starts moving between operations, IT, management and the vendor.
The review therefore starts with one real workflow rather than a platform shortlist. We reconstruct the decision from request to outcome: what evidence is required, what the system is allowed to do, who can accept or reject its recommendation, and where work goes when data is absent, contradictory or outside the intended context. That reveals the difference between a useful capability and an operable system.
We then make accountability part of the architecture. A decision and authority matrix names the workflow owner, the subject-matter reviewer, approval and override rights, the exception destination and the person with stop authority. An evidence plan defines what must be recorded. A baseline describes the current flow before a pilot is allowed to claim improvement.
This work respects the EU AI Act’s risk-based structure; it does not label every AI workflow high-risk. Where a system is in fact classified as high-risk, the specific provisions on lifecycle risk management, record-keeping and effective human oversight become relevant within their legal scope.
System method
Convert a promising pilot into an operable decision system
NIST AI RMF and TEVV are voluntary operating references, not certification or proof of EU conformity. They direct evaluation toward the actual workflow, failure conditions and decision context rather than model accuracy alone. Four steps then connect business consequence, human authority and technical evidence.
-
01
Trace the decision and baseline
Follow real cases from entry to outcome, identify handoffs and manual corrections, then define the current-state evidence against which a change can be judged.
-
02
Assign ownership and authority
Name the workflow owner, reviewer and approver; define what the AI may recommend or execute and who can override, pause or stop it.
-
03
Design the exception and evidence path
Specify human review for missing data, uncertainty, conflict and sensitive cases, with escalation rules and proportionate logging that preserves decision context.
-
04
Evaluate in the operating context
Test normal cases and failure conditions within a bounded workflow, compare observations with the baseline, and make an explicit go, revise or stop decision.
What the work produces
Four operating assets your team can challenge and use
The review ends with working artefacts that expose assumptions and make the next investment conditional on evidence.
AI system and decision map
The workflow, decision points, data sources, dependencies, system boundary and affected roles in one inspectable view.
Ownership and authority matrix
Accountable owner, subject reviewer, approval right, override, stop authority and escalation destination for each consequential step.
Control and evidence plan
Human review gates, exception handling, required records, retention logic and role-specific AI literacy considerations.
Baseline and decision brief
Current state, evaluation criteria, unresolved risks, dependencies and a reasoned recommendation to go, revise or stop.
Illustrative operating scenario
Illustrative scenario — not a customer caseA good recommendation with nobody authorised to own it
Illustrative scenario — not a customer case
A Vienna-based B2B team pilots an AI assistant to prepare complex proposal approvals. The recommendations look useful in the steering meeting. The first unusual case, however, contains stale contract data. Sales assumes Legal will review it; Legal expects the system to escalate; IT can confirm only that the service ran. The review does not add another approval button. It first names the decision owner, defines the actions the assistant may take, sets the minimum evidence for review and gives the exception a destination. The revised flow is then evaluated with ordinary and conflicting cases so the team can see whether people can understand, challenge and stop it.
Purpose: explain the method. No operating outcome is claimed. The scenario demonstrates the method only. It is not a client engagement and claims no realised operating result.
Execution roadmap
A 30/60/90-day path with real decision gates
-
Days 1–30
Map the flow, ownership and baseline
Select one consequential workflow, trace real cases, define the decision and evidence need, and expose ownership and risk gaps.
-
Days 31–60
Design controls and test a bounded flow
Build the authority matrix, human review gates, exception route and evidence plan; evaluate normal cases and defined failure conditions.
-
Days 61–90
Go, revise or stop
Compare observations with the baseline, document residual risk and operating burden, and make the next investment decision with explicit conditions.
Questions worth resolving
Questions worth resolving
What does an AI Systems Review examine?
One real workflow and its decision, owners, data, authority, human review, exception route and evidence. It produces a system map, authority matrix, control plan and a decision brief.
Is this ERP or CRM integration consulting?
No. An ERP or CRM may appear as a data source or dependency on the system map. The service concerns the operating architecture around AI-assisted decisions, not implementation or ongoing integration of an ERP or CRM product.
Is every AI workflow high-risk under the EU AI Act?
No. The framework is risk-based, and duties depend on the system, intended purpose and the organisation’s role. References here to Articles 9, 12 and 14 apply specifically where an AI system is classified as high-risk.
What does meaningful human oversight look like?
An authorised person receives enough context at the right time to understand limitations, challenge or override an output, and use a practical escalation or stop path. A generic approval button is not a complete oversight design.
What should we bring to the first review?
Bring one AI pilot or planned workflow, several de-identified real cases, the roles involved, current decision rules and known exceptions. Imperfect material is useful because missing evidence is itself a finding.
Primary references
References inform the operating context; they do not imply endorsement.
- European Commission — EU AI Act risk-based framework
- EU AI Act, Article 4 — AI literacy
- EU AI Act, Article 9 — risk management for high-risk AI
- EU AI Act, Article 12 — record-keeping for high-risk AI
- EU AI Act, Article 14 — human oversight for high-risk AI
- NIST AI Risk Management Framework 1.0
- NIST AI Test, Evaluation, Validation and Verification
Request an AI Systems Review
Bring the AI pilot that works in the demo but not yet in the operating model.
The first AI Systems Review frames one workflow, its decision owner, authority boundary, exception route and missing evidence. You leave with a candid view of whether architecture work is justified and what a responsible next step requires.