KoAssist vs. Leo AI.

Thought from the model, or from the document.

Leo AI starts at the geometry. The company describes its model as trained on native CAD geometry, and everything else follows: connections to the PLM systems where that geometry is managed, and the ability to produce editable starting models. Thinking that way, a part is a body first and paper second.

KoAssist starts at the document. A standard is a text with section numbers, a specification a list of requirements, a drawing a sheet with a title block and dimensions. The task is to find the passage and make it citable, not to build a new model. That is why we produce a page number and not geometry.

The second difference is the legal frame, and it is more concrete than it sounds. Leo stores only encrypted vectors and leaves the original files where they are. Architecturally that is leaner than our synchronised copy. In exchange Leo publishes no list of countries, while we put German data centres, EU language processing and the data processing agreement in writing. Which of the two commitments weighs more is your IT department's call, not ours.

When is Leo AI the better choice?

When the archive lives in Windchill or Teamcenter. Both are connected there and neither is here. For a company with a working PLM that is simply the deciding factor, and no other argument changes it.

When the AI should design and not only answer. Leo produces editable CAD starting models for four common systems. KoAssist cannot do that and does not plan to, because it is a different job.

When no second copy of the documents may exist. Leo stores only encrypted vectors. Where IT makes exactly that a condition, our synchronised copy is the harder conversation, even though it sits in Germany.

When is KoAssist the better choice?

When the documents are in German. Product, support and documentation are German, and the standards world is the local one: DIN, ISO, VDI, AD 2000. That is not a comfort issue but a question of accuracy when a question is asked in German engineering vocabulary.

When the knowledge does not sit in a PLM. Network drives, SharePoint, Outlook and the project archive that has grown over decades are connected here; Leo names Windchill, Teamcenter, Onshape and SOLIDWORKS PDM on its product page. Companies without an end-to-end PLM will not find their archive there.

When IT needs a written commitment. German data centres, language processing in the EU only, no third-country transfers, a data processing agreement under Article 28 and the technical and organisational measures attached. Leo commits to SOC 2 and GDPR principles but publishes no list of countries.

A company without PLM and thirty years of project folders

A plant builder works with SOLIDWORKS and its PDM, no Windchill, no Teamcenter. Project documentation has been sitting on a network drive for thirty years, sorted by customer name and year. The standards library sits next to it as PDFs, the discussions about it in Outlook.

Leo AI meets a system landscape here that it was not built for. SOLIDWORKS PDM is connected; the network drive and Outlook are not named on the product page. Most of this company's knowledge therefore sits outside.

KoAssist reads both. The question about the 2014 design case leads to the project file, the email with the customer approval and the standard the calculation was based on. What Leo does better in exchange: if the same plant builder needs a new bracket and wants a starting model produced, our remit ends.

To be fair: if this company introduces Teamcenter in two years, the calculation shifts. The knowledge then sits where Leo is at home.