# Owning your model · Insights · Dscvry > What it takes to train a model on your data and run it on your infrastructure: from your material to a tested model that you own. Source: https://dscvryai.com/insights/owning-your-model/ 1. [Home](https://dscvryai.com/) 2. [Insights](https://dscvryai.com/#insights) 3. Article Article # Owning your model What it takes to train a model on your data and run it on your infrastructure. - **Starts from** Your own documents, codes and terms - **Tested** Field by field, on examples the model has never seen - **Ownership** The finished model is yours and runs in your systems Most organisations that want AI on their own material end up in one of two places. Either they send their documents to a general model hosted somewhere else, or they build something in-house that never reaches the work. We take a third route: a model trained on your data, tested on your work, and handed over as something you run yourself. ## From your data to a working model The route starts with the material you already have: procedures, inspection reports, contracts, records and the sources your people actually read. We begin with the job rather than the benchmark. Which fields matter, which decisions follow from them, and where a mistake would be expensive? The answers decide what the model is built to do. This is the point of *custom models* and *fine-tuning* on our [models page](https://dscvryai.com/technology/models/) . For teams that do not have AI specialists of their own, the work is to turn their documents into a model that behaves like a specialist who already knows the material. ### Teaching it your codes, units and terms A general model reads a line such as “TWA 50 ppm, STEL 100 ppm” as two numbers. Someone who works in the field reads it as two exposure limits with different meanings and different consequences. That gap is why we teach each model your codes, units and terms, so it reads them the way your engineers, lawyers and analysts do. Vocabulary is the first thing a model learns, and it is the part a general model most often gets wrong. A hazard code, a gauge pressure or a clause reference means one thing inside your organisation and something else everywhere else. A model that has not been taught that difference will be confidently wrong. ## Domain training with your experts Reading your documents is not the same as judging them. For that we use domain training. Your industry’s material is the starting point, and your experts review what the model produces and correct it, until it judges the way they do. Their corrections are the signal that turns a model that reads your documents into one that makes the calls your people make. This also keeps the judgement where it belongs. The people who know the subject decide when the model is right, and the model is tuned to their standard rather than to ours. ## A smaller model on ordinary hardware Most narrow jobs do not need the largest model available. The aim is the quality of a large model in a small one that runs cheaply on ordinary hardware. Compact models run on ordinary GPUs inside your network, including fully air-gapped sites, with no calls to outside services. The result is a model you can afford to run all day, close to the data it works on. Size is a choice made on evidence, not on reputation. A large model that cannot run inside the restricted network it is needed in is not a useful answer, however capable it is in general. ## Tested field by field, and again after every change Before a model is trusted, we score it field by field on examples it has never seen, held back from training. Any field that falls below your bar is routed to a person until the model earns the right to handle it. We test again whenever the model changes, because a score from last month says nothing about this month’s version. A new version replaces an old one only when it scores better on the same held-back data. The scores, the data used and the reason for the decision are kept, so the record can be checked later by someone who was not in the room when the decision was made. ## Yours, running inside your systems The finished model is yours and runs inside your own systems. Your data only ever trains your model. What is learned from your documents is not used for anyone else, and retention and purge rules are set by your organisation. Where it runs is your decision too. The same model can be hosted by us, deployed in your cloud or VPC, or placed on your own servers, at the edge, offline or fully air-gapped. Our [deployment options](https://dscvryai.com/#deployment) set out each mode, and the choice follows where the data is allowed to go. Models also improve, so the system is built to be replaced, not frozen. A better model can be swapped in, but only on evidence from your own documents. [Our models, and yours](https://dscvryai.com/technology/models/) [Deployment options](https://dscvryai.com/#deployment) ## Bring us the work where wrong is expensive. Start with the operational problem. We’ll work out the data, models and agents it needs, and where it should run. [Talk to us →](https://dscvryai.com/contact/?topic=Owning%20your%20model) ## More insights - [Article The best AI strategy is sometimes no AI A client wanted AI in a workflow with fixed rules. We told them not to: ordinary code was cheaper, faster and easier to audit.](https://dscvryai.com/insights/best-ai-strategy-is-sometimes-no-ai/) - [Article Why our agents stop for a person Where an agent should hand over, and how to decide before it ever runs.](https://dscvryai.com/insights/agents-stop-for-a-person/) - [Article AI where nothing gets out Running models offline and air-gapped, close to the work.](https://dscvryai.com/insights/air-gapped-ai/)