Fathom avaa kokousdatan tekoälyavustajille MCP-palvelimen kautta

Fathom avaa kokousdatan tekoälyavustajille MCP-palvelimen kautta

Fathom julkaisi virallisen Model Context Protocol -palvelimen osoitteessa api.fathom.ai/mcp, jonka avulla ChatGPT, Claude ja muut tekoälyavustajat voivat hakea kokouslitterointeja, puhujakohtaisesti merkittyä dialogia, tekoälyn tekemiä yhteenvetoja ja toimenpidelistoja suoraan [1]. Se on suunniteltu vain lukua varten — käyttöoikeudet ja tietoturva säilyvät ennallaan — mutta se muuttaa käytännössä kokousarkiston kyselyrajapinnaksi mille tahansa MCP:tä ymmärtävälle LLM:lle.

GitHubissa on jo yhteisön rakentama palvelin, joka laajentaa tätä entisestään, ja Fathomin omat Zapier/Make-integraatiot täydentävät no-code-puolen [2][3]. X:ssä keskustelu keskittyy Fathomin ja Otterin käyttäjiin, jotka vertailevat omia MCP-asennuksiaan — yhteinen näkemys on, että kojelautaan lukittu kokousdata nähdään nykyään taakkana, ei ominaisuutena, kun kilpailijat avaavat sen agenteille.

Tämä on merkittävä signaali: MCP:stä on tulossa kokousälyn odotettu rajapinta, ei enää pelkkä mukava lisä.

Postgres ja pgvector nousevat yritystason RAG-ratkaisujen selkärangaksi

Kokoustyökaluista poiketen tietämyksen hakemisen taustalla oleva infrastruktuuri keskittyy yhä enemmän Postgresin ja pgvectorin ympärille. Tuoreet tuotantoon tarkoitetut oppaat kuvaavat hybridihakua — vektoripohjaisen samankaltaisuuden yhdistämistä avainsana-/BM25-/trigrammihakuun HNSW-indeksien avulla — ratkaisuksi, jota tiimit valitsevat, kun ne eivät halua erillistä vektoritietokantaa [1]. AWS:n kirjoitus CORTOn oikeudellisesta hakujärjestelmästä on erinomainen esimerkki: 7,6 miljardia vektoria 2,5 miljardin dokumentin joukossa 46 teratavun Aurora-klusterissa, kyselyaikojen ollessa alle 30 millisekuntia [2].

Datasopsin ja muiden viesti on suora: jos Postgres on jo käytössä, pgvectorin lisääminen voittaa useimmissa tapauksissa erillisen Pinecone- tai Weaviate-järjestelmän pystyttämisen — kunhan lohkominen, metadata ja asiakaskohtainen eristäminen hoidetaan oikein [3]. X-keskustelut tuovat mukaan myös tietoturvanäkökulman — uudelleenjärjestelyn (reranking) ja istuntokontekstin käytön suojaamaan hakutietojen myrkyttämiseltä yritysympäristöissä.

Kaikille yrityksille, jotka rakentavat "kysy datastasi" -ominaisuuksia — mukaan lukien kokoustietopankit — tämä on se hiljainen arkkitehtuuripäätös, joka ratkaisee, onko tiedonhaku nopeaa, edullista ja luotettavaa suuressa mittakaavassa.

EU:n tekoälyasetuksen valvontavaltuudet astuvat voimaan GPAI-malleille

2. elokuuta 2026 alkaen EU:n tekoälytoimisto ja kansalliset viranomaiset saavat todelliset valvontavaltuudet yleiskäyttöisiin tekoälymalleihin — oikeuden vaatia teknistä dokumentaatiota, varmistaa läpinäkyvyysvelvoitteiden noudattamista, tarkistaa tekijänoikeuksien noudattamista ja auditoida turvallisuustoimenpiteitä systeemisen riskin malleissa [1][2]. GPAI-dokumentaatio- ja koulutusdatan yhteenvetovaatimukset ovat olleet voimassa jo elokuusta 2025 lähtien; tämä seuraava vaihe koskee aktiivista auditointia, ei pelkkää paperityötä [3].

Toimittajat lähettävät tietonsa EU:n SEND-alustan kautta, ja pohjoismaisten sekä laajemmin eurooppalaisten yritysten, jotka rakentavat GPAI-mallien varaan — mukaan lukien kaikki, jotka tuovat tekoälyominaisuuksia kokous- tai tietämystyökaluihin — kannattaa varautua siihen, että riskienhallinta- ja läpinäkyvyyskäytäntöjen tarkastelu kiristyy. Korkean riskin järjestelmien säännöt tulevat voimaan vasta vaiheittain vuosina 2027–2028, mikä antaa vielä aikaa sopeutua, mutta GPAI-taso on jo nyt voimassa.

X:ssä kommentoidaan, että tämä on hetki, jolloin tekoälyasetus lakkaa olemasta teoreettinen eurooppalaisille tekoälytoimittajille — tekijänoikeuskiistojen sovinnot mainitaan varhaisena varoitusmerkkinä siitä, kuinka vakavasti dokumentaatiopuutteisiin tullaan suhtautumaan.

Mitä tämä tarkoittaa kokouksillesi

Tämänpäiväiset uutiset viittaavat samaan taustalla olevaan muutokseen kahdesta suunnasta: kokoustyökalut kilpailevat siitä, kuka tekee datastaan toimintakelpoista (Fireflies CRM-järjestelmiin, Fathom tekoälyavustajiin MCP:n kautta), samalla kun infrastruktuuripuoli ratkoo, miten valtavat datamäärät saadaan haettaviksi nopeasti ja suuressa mittakaavassa (Postgres/pgvector, hybridihaku). Yhdessä nämä tarkoittavat, että vuonna 2026 kokoustyökalun rima ei ole enää "litteroiko se tarkasti" — vaan "pystyykö se viemään faktat järjestelmiin, joissa työ oikeasti tapahtuu, ja voiko tekoälyavustaja kysellä koko historiaa tarpeen mukaan."

Proudfrogille tämä vahvistaa tietämysverkkoon (knowledge graph) perustuvan lähestymistavan: litterointi on lähtökohta, ei lopputuote. Todellinen tuote on kyseltävä, puhujakohtaisesti merkitty, kokousten välinen muisti, joka kytkeytyy sinne, missä päätökset tehdään — olipa kyse sitten CRM-tietueesta, Slack-keskustelusta tai Claudelle esitetystä kysymyksestä "mitä me sovimme tämän asiakkaan kanssa kolme kokousta sitten?" EU:n tekoälyasetuksen valvonta-aalto on tässä myös suoraan merkityksellinen: minkä tahansa työkalun, joka tallentaa ja hakee henkilökohtaista kokousdataa tietämyskannasta, on oltava dokumentoitu ja auditoitava tekoälykäytäntöjensä osalta jo nyt, ei myöhemmin — tämä ei ole tuleva vaatimustenmukaisuusongelma pohjoismaisille ja eurooppalaisille tiimeille, vaan ajankohtainen jo nyt.

Ne organisaatiot, jotka voittavat tulevan vuoden "kokousälykkyyden" kilpailussa, ovat niitä, jotka kohtelevat litterointeja pysyvänä, jäsenneltynä ja haettavana tietona — eivät kertakäyttöisinä muistiinpanoina — samalla kun ne pitävät kirkkaana mielessä, miten kyseistä dataa käsitellään ja hallinnoidaan.

Keskeinen huomio: Kokousdatasta on tulossa pysyvää, kyseltävää infrastruktuuria — voittajia ovat ne työkalut, jotka tekevät siitä samanaikaisesti sekä tekoälyn haettavissa olevaa että EU-lainsäädännön mukaan puolustettavissa olevaa.

Sources

1. https://guide.fireflies.ai/articles/7197167809-how-to-set-up-salesforce-and-fireflies-integration
2. https://guide.fireflies.ai/articles/8145727698-how-to-setup-fireflies-with-hubspot-integration
3. https://affine.pro/blog/fireflies-ai-integrations-list-tips
4. https://developers.fathom.ai/mcp-docs
5. https://github.com/agencyenterprise/fathom-mcp-server
6. https://www.fathom.ai/integrations-workflow-automation
7. https://suparbase.com/blog/pgvector-rag-production
8. https://aws.amazon.com/blogs/database/cortos-billion-scale-legal-semantic-search-with-aurora-postgresql-pgvector/
9. https://datasops.com/blog/vector-databases-production
10. https://digital-strategy.ec.europa.eu/en/policies/enforcement-ai-act
11. https://artificialintelligenceact.eu/implementation-timeline/
12. https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers