Many AI-leadership candidates can present strategy, but fewer can show production artifacts. Hiring managers know this and look for evidence — not by claims alone, but by artifacts: running systems, repositories, evals, and production metrics. Below are direct answers to eight clusters of questions that HR and hiring managers ask about an AI-Driven Head of Engineering profile. Each section states the claim, the supporting evidence, and any limitation.
Sanctions hygiene: the employer-integrator is referenced by the descriptor "large systems integrator" — not by name; the named anchor for public cases is Askona.
Hands-on: What's Built and Where It Runs
The primary filter for an AI leadership profile is not the title or the number of managed engineers. It is the answer to one question: which production systems have you personally designed, built, or operated?
Over the past year: two working AI systems built solo — a delivery-intelligence system running on live projects (ai-delivery.dobryakov.net) and a market-intelligence and content-operations system (nextmoveengine.com). A public MCP server for the profile (dobryakov.net/mcp.html), open-source code at github.com/dobryakov. The delivery-intelligence system has been running in production for about two months across two projects — catching estimate discrepancies, missed responses, and contradictions in documents.
At Askona: AI-assisted development in a live enterprise context — next best offer (ML), timestamp tracker, geo-resolver proxy, AI bot to the data lake (NL→SQL). The public howto series contains reproducible artifacts, not trend retellings: jira-clarify-bot, bots-discuss-spec, eval-harness, enterprise-code-bastion, egress-redaction-gate, ai-n8n-workflow-builder, git-evolution-audit.
The same patterns recommended to teams are used in the author’s own systems. Everything recommended to teams — RAG, event-driven agents, eval gates, knowledge architecture — is already built and running in production. Over 20+ years, the path has run through CTO and enterprise architect roles, while continuing hands-on system design and implementation. System design and hands-on assembly continue.
Unlike an advisory-only role, this mandate includes ownership of implementation and outcomes. Here we are talking about ownership of the function and accountability to the board for the outcome. The format is fulltime, not fractional. The proposed role is implementation ownership, not a preliminary audit of the engineering/delivery function into an AI-native operating model with ownership of the result.
Team: Making AI Practices Reproducible Across the Team
The question "what remains when you leave?" is the right one. The answer: documented practices, trained leads, and shared ownership rather than dependence on one specialist.
At Askona: dozens of training events with audiences of 100–200 people — engineering practices, management approaches, and applied AI. Real services were assembled at those same sessions. By year 3–4, new principles and architecture were defended by the team itself — including those who were initially skeptical of the changes. The practices became the catalyst for spinning off a dedicated AI division in the company.
At UMI, the team continued applying the introduced methodologies after the turnaround ended — including on other projects.
Skeptical engineers are brought in by mapping the change to concrete technical ownership and skill growth. Transitioning to AI or a new architecture is framed as a skills upgrade with real ownership of new components. An engineer on legacy sees growth, not a threat. The rollout is staged: first low-risk components, then wider adoption after results are visible. A skeptic who becomes convinced that their expertise is becoming more valuable often becomes an internal advocate for the change.
Governance: Security and Governance Built Into the AI Architecture
Security requirements are defined at design time and enforced through isolation, provenance, redaction, and audit controls. The default perimeter: data isolation (data stays within the authorized boundary), source labeling by trust level, prompt-injection defense, audit trail on every fact, and human-in-the-loop checkpoints at all autonomous steps. For environments where an LLM cannot be given access to files or a shell, the enterprise-bastion pattern applies: --tools "", MCP-only, command filtering, execution in an isolated container (enterprise-code-bastion, repository).
The hallucination problem is addressed by three mechanisms. First: provenance on every fact — any claim is traceable to a source with a timestamp; the system does not confuse "said on a call" with "a signed obligation." Second: a contradiction detector — when sources diverge, it is flagged, not silently overwritten. Third: eval as a release gate — an AI feature does not ship to production without passing a regression suite built from real incidents and human spot-checks (eval-harness).
On compliance (GDPR, EU AI Act, data residency): the AI perimeter is designed with predefined trust boundaries, audit logs, data minimization, and human review — human-in-the-loop, data isolation and minimization, audit trail, data placement in the required jurisdiction. For each AI scenario, what data crosses the trust boundary and on what basis is fixed in advance. Risk classification following EU AI Act logic is handled during architecture design rather than after implementation.
Honest disclaimer. There is no formal audit for compliance with a specific regulation in the public perimeter. The public materials show engineering controls — isolation, egress redaction of PII and secrets, human-in-the-loop — that such compliance rests on. Egress redaction demo: dobryakov.com/howto/egress-redaction-gate.
ROI: Business Metrics, Not Velocity
The relevant AI metrics here are business outcomes: revenue, defect inflow, release frequency, time-to-insight, margin, and client satisfaction.
Concrete data:
UMI (CTO, SaaS turnaround): revenue +50% YoY; new defect inflow reduced from 5–10 per day to ≤5 per week; releases moved from "once every few months" to "nearly weekly."
Askona (enterprise): AI bot to the data lake — Time-to-Insight went from several days (Jira queue) to seconds.
Delivery system management KPIs: scope compliance, commitment tracking, age of open questions — metrics that directly affect margin and client satisfaction.
Where there are no numeric KPIs in the public perimeter, the answer is honest: "qualitative." For example, at Askona, metrics on approval cycles were not collected, but task assignment and approval accelerated due to AI validation and fewer manual iterations. An estimate is not presented as a fact.
Honest disclaimer on AI limitations. A clarify gate without project context asks generic questions that the client ignores — without context, the tool does not get adopted. Cross-org negotiation without an explicit trust model is a raw tool, not a production product. "Demo-grade ≠ production-grade": an AI feature without an eval harness does not ship to production. The evaluation also includes cases where AI is rejected because it does not improve the process.
Honest disclaimer on attribution. Public business metrics are metrics of the organizations as a whole, not a direct measurement of one program's contribution.
Org Design and the First 90 Days
AI adoption should change development, testing, review, product features, and operational feedback loops, rather than sit only in a separate team. Teams use AI in development, testing, and review on their own; the product includes AI functionality designed for reliable production operation; operational circuits receive signals from data.
Where companies hire a VP of Engineering and a Head of AI separately, this profile covers both levels with unified accountability: people and delivery, systemic AI integration, and ensuring the entire agent system works as an operating model rather than isolated experiments without production ownership or shared governance. The role is intended to cover gaps that appear when these responsibilities are split. A VP without AI, a Head of AI without delivery, a consultant without ownership of the outcome — each has an obvious weakness.
The framework for the first 90 days, validated across four turnarounds of increasing scale:
Days 0–30 — diagnose delivery, AI attempts, data flows, and governance before changing the system. Capture the real state: where delivery stalls, where AI was already tried and why it did not reach production, where the data and governance sit. The instrument is an architectural retroanalysis of git history (deterministic metrics + interpretation), not just interviews. No major reorganization is made before the current operating constraints are understood.
Days 30–60 — first scoped production improvements. One or two narrow but visible circuits: a requirements clarify gate, a release eval gate, AI applied to one painful delivery process. A win with a clear owner and a metric, not an experiment without owner, metric, or production path.
Days 60–90 — transfer practices to team leads and define ownership. Training and mentoring leads so that AI practices become a team asset. Fix roles, areas of responsibility, and success criteria for the AI direction.
At Askona, the effect manifested in the first two years; the culture solidified by year 3–4. Phasing over a "big bang" is a validated method, not caution.
On build vs buy vs partner: the decision is made regularly and on TCO, not on hype. Build where it is a core differentiator and an outcome owner is needed; buy where it is a commodity with a good SLA. In a large enterprise, a make-or-build-or-partner decision for new services came up every 1–2 months: technical validation of contractors before onboarding, resisting premature outsourcing, recording vendor failures, and using those outcomes in future decisions.
Technical Stack and Resilience to the Speed of Change
Validated stack: Anthropic Claude (API, MCP, tool use), OpenAI-compatible interfaces, Gemini (Python/n8n); event-driven layer (Kafka, RabbitMQ, webhooks), vector stores, ElasticSearch/ClickHouse; cloud/IaC (AWS, Docker, Ansible).
Model selection is driven by the task and the trust boundary, not by brand. Where tool-use and controllability are needed — Claude/MCP. Where cheap mass inference is needed — whatever delivers price per token at acceptable quality.
The answer to "how do you keep up with the speed of change" is architecture that is resilient to model replacement. Contracts, eval gates, and provenance do not depend on which model is under the hood today. Models can be swapped if interfaces, evals, provenance, and trust boundaries are stable. Stack choices are validated through maintained systems, repositories, and howto examples: a blog, a howto series, and personal systems are all live.
For working with legacy without breaking business continuity: AI is integrated into an already-running production circuit with respect for architectural and security constraints, in phases. Askona — AI practices in a live enterprise context ($680M+, 40+ services); PersonaClick — modernization of a legacy personalization platform handling 199M+ profiles, migration of ML from batch to streaming retraining.
People Management: Hiring, Performance, Exits
Competency matrices and grades are used for hiring, growth plans, feedback, and PIPs. On that basis — individual growth plans and, where needed, formal PIPs tied to named gaps. Regular early feedback, including heavy corrective feedback; when someone falls short — root-cause diagnosis (skill / motivation / wrong role) before a decision to exit.
At UMI during the SaaS turnaround, the conservative part of the team including the architect was exited, and more than half of the new people were hired. The point is not broad replacement, but distinguishing trainable gaps from role mismatch or persistent underperformance.
Retention works through real ownership of outcomes and mentoring (developing through questions, not ready answers). Conflicts are handled through mediation and de-escalation without destroying working relationships. In distributed teams, scale is achieved through local senior leads in each office, so decisions are made without centralizing all authority. Psychological safety means engineers can raise risks and errors without punishment for the act of reporting them.
Pushing investments upward: investment cases are framed through architecture impact, TCO, and the cost of deferred modernization; the argument "modernize now vs. fight fires incrementally." Onboarding incoming executives (including a new CIO). The ability to reject premature architectural bets even when there is internal pressure to approve them when an architectural bet is premature — the cost of getting that wrong at scale is measured in years of debt.
Logistics: Format, Location, Compensation
Fulltime, fully remote. Base — Serbia/Montenegro, CET/CEST — full overlap with EU working hours. Work permit in Montenegro (renewable); possible engagement through an EOR or as a contractor. Horizon — from one year. The target role should include authority to change engineering and delivery practices.
English is a working language; public expert content and the profile are maintained in English (LinkedIn, dobryakov.net). Russian is native. Distributed multilingual teams are a comfortable environment.
On "job hopping": the profile is a turnaround specialist. The call is to fix what is broken or stabilize delivery, clarify ownership, and rebuild engineering processes, not to maintain a steady state. By definition, this is a project-spirited mandate with the first phase is expected to produce visible operational improvements. At the same time, the enterprise track is multi-year: Askona — years, with culture solidifying by year 3–4. Four turnarounds of increasing scale form a sequence of turnaround roles with increasing scale.
Compensation range — benchmark: senior engineering leadership (Head of Engineering / Head of AI) in a fully-remote EU context. The specific range depends on the engagement form (EOR vs. contractor), mandate scope, and composition (equity/bonus). Discussed on the details of the role.
Best-Fit Company Context
The profile combines engineering leadership with hands-on AI engineering. A VP without AI covers delivery but runs pilots. A Head of AI without delivery builds models but does not run the organization. A consultant without outcome ownership leaves with recommendations.
This profile is for companies that need one person accountable for the entire system: people, delivery, and AI integrated into engineering, delivery, governance, and product operations — supported by public systems, repositories, howto materials, and stated limitations.
Contact details are available in the linked profile and public site.