Technical Project Manager (AI)

AddanEx JOB POSTING:
Title: Technical Project Manager (AI)
Location: Stockholm, Sweden
Onsite / Remote: Onsite 2-3 days per week
Type: Contract
Start Date: ASAP / September – October
Duration: 6 Months + Extensions
Utilisation: 40 Hours per week
Languages: Swedish & English

Job Summary / Key Skills

• Delivered technical projects across organisational boundaries in a large enterprise, things that finished
• Has driven deliveries through a formal IT service-introduction or ITSM process (service portfolios, solution documents, governance-forum approvals, CMDB, service-desk handover).
• Security or compliance change delivery through an InfoSec/risk function
• Taken a SaaS product from evaluation to production in an enterprise: assessment, contract, identity integration, rollout
• Written English of publishable quality, the main output is documents other people act on
• A hands-on, daily AI user: already produces real working documents with LLM assistants and can show it; knows how to prompt, verify and edit AI output rather than paste it. The role's document volume assumes AI-assisted production from day one
• Technically conversant to the depth of a real discussion: can talk through RBAC models, API scopes, SSO flows and data classification without needing terms explained. Time as product or project manager for a backend or platform team is the right shape of background.
• Comfortable operating without authority
• Deliberately not required: PM certifications (PMP/PRINCE2/SAFe), line-management experience, deep engineering.

Task:
The client is setting up a central AI team to make AI easy to consume, safe by default and financially accountable across a decentralised group of 42,000 people. The AI platform and its operations are run by a small engineering team; policy is set by Legal and the CISO's security initiative. This engagement is the first person into the new team.

The Job:
Drive the non-engineering work that currently blocks the programme, across organisational boundaries where the team has no authority to compel anyone:

• Security and compliance changes: run them as tracked deliveries to closure: scope, owners, sign-off. Coordinate InfoSec, Legal and division owners; the role makes reviews finish, it does not perform them
• AI tool intake and onboarding: build and run the end-to-end path for new AI services, in both shapes: external tools brought in (the first external tool is in intake now: assessment, data-classification review, commercial with Procurement, identity setup, pilot, rollout, decision record) and internally built products launched as Service Offerings (the same path while the product is being productised: solution documentation, support model, pricing). These are first-of-their-kind runs; the process is being written by running it
• Integration assessments and scope-change re-assessments: existing integrations whose permissions widen or grow new components. The group-wide collaboration platform is the expensive case: changes to an existing integration there trigger a security revision of the Technical Solution Document; changes elsewhere are light. Two live examples, both on the expensive path: a connector originally assessed with read scopes now has write, and an add-in is waiting on enablement. The role drives each end to end: TSD security revision, approvals, configuration, rollout
• The approval legwork: the approvals are internal. Client runs a formal Group IT service-introduction process (impact analysis, anchoring decks in governance forums, a Technical Solution Document, an ordered security review, Service Portal offerings, CMDB, business pilot, service-desk handover). The role drives AI services through that process: the meetings, the decks, prompt answers to security's questions, one-to-one alignment with the people who each hold a piece of the yes. This is the majority of the job, and the candidate should see it as the job, not as overhead around it
• Documentation: the intake process, runbooks, decision records, the AI use-case register, and the policy-to-control mapping (policy itself is set elsewhere). The volume is high and most of it is produced with the AI assistants the platform itself provides: drafting with AI and editing to publishable quality is the working method, not an aspiration
• Programme cadence: one status view: what is in flight, what is blocked, who owes what by when
• Boundary agreements: carry five written scope agreements (Product Compliance, DevX, InfoSec, data organisation, the CISO's AI-policy initiative) to signature

Delivered by month six:

1. One status view of every change, onboarding and boundary agreement in flight, owner and next date on each
2. Tool intake process v1 written, published with an SLA, and exercised end to end on the first external tool being brought in
3. The open integration changes closed: the connector re-assessment (read to write) and the add-in enablement, both through assessment to production
4. At least two of the five boundary agreements closed in writing
5. AI use-case register at a first honest baseline: what runs, who owns it, what data it touches
6. Handover package to the permanent governance hire, written as the work happens, not at the end