Skip to content
Neurons Lab.Com

Forward-Deployed AI Architect

Italy; Portugal; Slovenia; Cyprus; Greece; Serbia; Hungary; Spain; Slovakia; Lithuania; Greece; Albania; Poland; Czech Republic; Moldova; Ukraine; Bulgaria; Estonia; Macedonia; RomaniaRemote · Europe
Staff · Contract · AI Engineering
POSTED 20 OCT
Apply Ask
Role
20 days opentrue age
Posted 20 Oct
Pay
€70k–€80kno pay posted
Market p25–p75
€70k–€80k
Portugal · n=5 · 365d to 4 Nov
CompanyNeurons Lab.Com →
7open roles
Opened · 30d
+0
Closed · 30d
−0
30d window
Market
9,271open · Staff Software engineering
Opened · 7d
+4845% of open
All software engineering
75,164open
All tracked boards · live 10 Nov · n=9,271
Go

About the role

We are looking for a hands-on Forward-Deployed AI Architect to lead the technical delivery of an AI-assisted operations platform for an enterprise client in travel disruption management.

The current phase covers three connected workflows:

Processing and routing service requests

Ranking and recommending hotels

Closing cases with billing reconciliation and downstream system handoff

You will turn operational knowledge and existing software into a working, testable system with explicit human approvals and traceable decisions.

This is technical leadership, not architecture-only advice or task execution. You will work directly with operational experts, the client’s technology partners and our engineers, challenge assumptions constructively, and carry the technical solution from discovery through implementation and evaluation.

How you will work

You own the technical approach, engineering plan, implementation quality and evidence of readiness. You partner with the engagement Principal, who owns the integrated delivery plan, commercial scope and client commitments. You provide feasibility assessments before commitments are made and escalate unresolved dependencies or scope changes with options and their impact.

What you will own

1. Establish an evidence-based technical baseline

Inspect the code, infrastructure, APIs and operator workflows before estimating the build.

Translate discovery into concise specifications with inputs, outputs, exclusions, acceptance tests and source references.

Distinguish confirmed requirements from analyst recommendations and assumptions.

Resolve contradictions with the appropriate owner. Do not implement them silently.

2. Make integration work early

Build and review critical components, guide engineers and prove a thin end-to-end path in the client’s test environment: receive a request, retrieve operational data, produce a recommendation, obtain approval and perform the agreed system handoff.

Verify API access, write capabilities, event contracts and error paths. Do not treat documentation or isolated components as proof of readiness.

3. Make rules and knowledge maintainable

Design a clear separation between operational facts, business policies and software logic.

Work with named business owners to define rule precedence, exceptions, validation and approval.

Keep draft or inferred rules separate from approved rules.

Support versioned updates without a software release, with historical replay, traceable approval and rollback.

Use grounded reasoning and human escalation where rules do not resolve a case.

4. Own engineering quality and evaluation

Review and test code, including AI-generated code, against the agreed architecture.

Establish automated CI checks, integration tests and representative operational cases.

Track the exact application, rule and data versions evaluated.

Implement decision logs, monitoring, access controls and failure recovery.

Define test-readiness evidence and agree workflow-quality, latency and operating-cost measures with the team and client.

5. Keep technical decisions and progress clear

Maintain a concise architecture and decision record that shows what works, what remains and why.

Raise blockers early with evidence, an owner, a decision needed and delivery impact.

Propose simpler alternatives and update estimates when assumptions change.

Demonstrate working increments, and clearly distinguish prototypes from integrated functionality.

Leave the team with maintainable code, documentation and a practical handover.

What good looks like

Before build commitments: a reviewed technical baseline, verified critical dependencies and explicit assumptions behind the estimate.

During delivery: a working end-to-end increment, automated tests running in CI, and demonstrated progress against agreed acceptance cases.

For rule changes: a named business approver, a versioned baseline and recorded replay results before promotion.

At evaluation: reproducible results, decision traces and documented limitations that support the agreed Go/No-Go decision, not just a successful demo.

Source · Neurons Lab.ComFirst seen 7 NovOriginal ↗