Tuomas Pasanen

AI-First Data Delivery

The bottleneck was never the people. It's the handovers.

A typical data request still moves through the same sequence: business asks, an architect designs, a data engineer builds the pipeline, a BI developer builds the report, someone tests it, someone documents it. Each step is a handover, and every handover loses a bit of what the business actually meant. Making each of those steps individually faster doesn't fix that — the request still crosses the same number of desks.

AI doesn't speed up the roles. It removes the handovers.

The shift I work with isn't a faster version of the old chain. It's giving AI the full context of the project at once:

The data sources and how they actually behave
The data platform in use
Existing documentation and the codebase, read straight from the git repo
The business requirement and the decision it needs to support
The organization's policies and guardrails for how data — and AI — is allowed to operate

With that in place, the same context carries through architecture, modeling, pipeline, validation and reporting — instead of being re-explained at every handover. And it starts from a clear specification, not an open-ended prompt: what data, what business rule, what decision this needs to support. AI drafts against that specification. It doesn't guess its way there.

What I actually do — and what stays with the team

Today I work as a Data Solution Lead. I lead the project and cover most of the roles myself, in direct dialogue with AI: I negotiate demand with the business, direct the project, specify the work, and analyze the code and the data.

What I don't do is push the final change to production myself. That's done by the data engineers on the team — not because I couldn't, but because it's better when responsibility for what ships stays shared across the team, not concentrated in one person.

The idea was never that everyone else stops working. It's that the distance from a business requirement to an architecture decision, to a spec, to something delivered, shrinks dramatically with this way of working.

In practice

Led architecture, specification and delivery for data platforms AI-first, while engineering teams kept ownership of what ships to production.
Cut the distance from business requirement to production-ready change from sprints to days.
Built governed data platforms and pipelines where AI drafts the work and people decide.

A more sustainable way to work

There's a second reason this matters to me, beyond speed. In the old model, the context of a project — what was decided, why, what the constraints are — lived mostly in people's heads, and keeping it there is exhausting. When that context lives in AI's memory instead, and stays current there, people's own attention can actually rest. That's not a minor side effect. It's what makes hectic IT work sustainable instead of just faster — and I think it's a better foundation for how data teams should work, long term.

AI-First Data Delivery

Pullonkaula ei ole koskaan ollut ihmiset. Se on kapulanvaihdot roolien välillä.

Tyypillinen datapyyntö kulkee yhä saman ketjun läpi: bisnes kertoo tarpeen, arkkitehti suunnittelee ratkaisun, data-insinööri rakentaa pipelinen, BI-kehittäjä rakentaa raportin, joku testaa sen, joku dokumentoi sen. Jokaisen vaiheen välissä on kapulanvaihto — aivan kuten viestijuoksussa: kapula vaihtaa kättä, ja joka vaihdossa on riski, että jotain putoaa matkalla. Käytännössä se tarkoittaa, että seuraava henkilö tulkitsee edellisen työn omalla tavallaan, osa alkuperäisestä tarpeesta jää kertomatta, ja lopputulos vastaa yhä vähemmän sitä mitä bisnes alun perin halusi. Silloin tarvitaan uusi kierros selvittelyä ja korjausta — ja se on se, mikä oikeasti hidastaa projekteja, ei yksittäisten vaiheiden hitaus. Vaikka jokaista vaihetta nopeutettaisiin erikseen, pyyntö kulkee silti saman määrän käsipareja.

Tekoäly ei nopeuta rooleja. Se poistaa kapulanvaihdot.

Muutos jota teen, ei ole nopeampi versio vanhasta ketjusta. Sen sijaan että jokainen ihminen saisi kapulan hetkeksi käteensä ja joutuisi arvaamaan mitä edellinen tarkoitti, projektin koko konteksti annetaan tekoälylle kerralla:

Datalähteet ja miten ne oikeasti käyttäytyvät
Käytössä oleva data-alusta
Olemassa oleva dokumentaatio ja koodikanta, luettuna suoraan git-repositorystä
Bisnesvaatimus ja päätös, jota sen pitää tukea
Organisaation politiikat ja suojakaiteet sille, miten dataa — ja tekoälyä — saa käyttää

Kun tämä on paikallaan, sama konteksti kulkee mukana arkkitehtuurin, mallinnuksen, pipelinen, validoinnin ja raportoinnin läpi — sen sijaan että se selitettäisiin uudelleen jokaisessa kapulanvaihdossa. Ja se lähtee liikkeelle selkeästä speksistä, ei avoimesta promptailusta: mitä dataa, mitä liiketoimintasääntöä, mitä päätöstä tämä tukee. Tekoäly luonnostelee sitä speksiä vasten. Se ei arvaile sinne.

Mitä oikeasti teen — ja mikä jää tiimille

Toimin tänä päivänä Data Solution Leadina. Johdan projektia ja hoidan suurimman osan rooleista itse, suorassa vuoropuhelussa tekoälyn kanssa: neuvottelen tarpeista bisneksen kanssa, ohjaan projektia, speksaan työn ja analysoin koodin ja datan.

Sitä mitä en tee, on lopullisen muutoksen vieminen tuotantoon itse. Sen tekevät tiimin data-insinöörit — ei siksi etten voisi, vaan koska on parempi että vastuu siitä mitä viedään tuotantoon pysyy jaettuna tiimissä, ei keskity yhteen ihmiseen.

Ideana ei koskaan ollut, että muut lopettaisivat työnsä. Ideana on, että matka bisnesvaatimuksesta arkkitehtuuripäätökseen, siitä speksiin ja siitä toimitukseen lyhenee huomattavasti tällä tavalla työskennellessä.

Käytännössä

Johtanut data-alustojen arkkitehtuuria, speksausta ja toimitusta AI-first-periaatteella, samalla kun insinööritiimit ovat pitäneet omistajuuden siitä mitä viedään tuotantoon.
Lyhentänyt matkan bisnesvaatimuksesta tuotantovalmiiseen muutokseen sprinteistä päiviin.
Rakentanut hallittuja data-alustoja ja pipelineja, joissa tekoäly luonnostelee työn ja ihmiset päättävät.

Kestävämpi tapa tehdä työtä

Tähän liittyy toinenkin syy, nopeuden lisäksi. Vanhassa mallissa projektin konteksti — mitä on päätetty, miksi, mitkä ovat rajoitteet — asui pääosin ihmisten päässä, ja sen siellä pitäminen on uuvuttavaa. Kun konteksti asuu sen sijaan tekoälyn muistissa ja pysyy siellä ajan tasalla, ihmisen oma tarkkaavaisuus voi oikeasti levätä. Se ei ole pieni sivuvaikutus. Se on se, mikä tekee hektisestä IT-työstä kestävää eikä vain nopeaa — ja mielestäni se on parempi perusta sille, miten data-tiimien pitäisi toimia pitkällä aikavälillä.