How to build artificial intelligence depends on what you want to build. A customer chatbot, a document classifier, and a language model trained from scratch are different projects. For most product teams, the first viable step is to create an application that uses an existing model through an API, tests a real task, and controls data, cost, and quality. Training a model from initial weights only makes sense when you have the data, expertise, and computing capacity to justify that choice.
Quick answer: define a measurable task, assemble 30 to 100 representative examples, build a prototype with an existing model, evaluate the errors, and only then decide whether you need document retrieval, fine-tuning, or your own training. “Building AI” does not require the first version to train a new model.
Choose the project type before choosing the technology
| Objective | Reasonable first approach | Who maintains the model? | Main risk |
|---|---|---|---|
| Answer questions or generate text in a product | Integrate a model API | API provider | Incorrect responses, cost, and data sharing |
| Answer based on company documents | Model API plus search/retrieval | Model provider; your team maintains the index | Outdated documents or unauthorized access |
| Adapt a model to a specific task | Fine-tune a permitted model | Your team or the selected service | Poor data and less gain than expected |
| Create a language model from the ground up | Train your own weights | Your team | Data, GPUs, evaluation, and operation at scale |
A chat interface can be “your AI” even when the base model comes from a vendor. The product's value lies in the task it solves, the experience, access rules, data integration, and continuous evaluation. Google's practical introduction to machine learning is a good starting point for understanding training, validation, and metrics before investing in infrastructure.
Step 1: describe a small, verifiable task
Avoid starting with “an AI that does everything.” Choose something like “classify support emails into five categories,” “summarize tickets with next steps,” or “answer questions about a help center.” For each task, define the input, output, user, constraints, and success condition.
Create an initial set of real examples, without unnecessary personal data. Note the expected result and difficult cases: mixed language, incomplete requests, content that does not exist in the knowledge base, malicious instructions, and contradictory documents. Separate development and test examples. If you adjust the prompt using all examples, you will no longer have an independent sample to determine whether the system improved.
Choose metrics that fit the task. Classification can use accuracy by category and the human review rate. A support response may require factual correctness, source citation, response time, and cost per resolved case. The number of tokens alone does not measure usefulness.
Step 2: prototype with a model API
An API reduces the initial work of hosting GPUs and serving the model. It does not eliminate product decisions: your team still needs to protect the key, format the input, validate the output, and handle failures. The Flatkey-compatible interface documents https://router.flatkey.ai/v1 for chat completions calls with the OpenAI SDK. Use a key issued by Flatkey and a current model alias from the catalog; do not confuse that key with a credential issued directly by OpenAI.
import os
from openai import OpenAI
client = OpenAI(
base_url="https://router.flatkey.ai/v1",
api_key=os.environ["FLATKEY_API_KEY"],
)
answer = client.chat.completions.create(
model=os.environ["FLATKEY_MODEL"],
messages=[
{"role": "system", "content": "Classifique a mensagem em: compra, suporte, cobrança ou outro. Responda apenas com uma categoria."},
{"role": "user", "content": "Não consigo encontrar a fatura do mês passado."},
],
)
print(answer.choices[0].message.content)This code is an integration test, not a production-ready application.
Validate the returned category against the allowed list, log only the
necessary data, set a timeout, and test 400,
401, 429, and 5xx errors. Store the key on the
server or in a secrets manager; never distribute it in
public JavaScript or in a mobile app.
If you choose to call a provider directly, read the current reference for its endpoint. Endpoints described as “compatible” may cover different surfaces: verify the model, tool format, streaming, limits, and billing. For an initial test, a small call is more useful than migrating all traffic at once.
Step 3: improve the result before training
When the prototype fails, classify the reason. Was the request ambiguous? Was data missing? Did the model receive too much context? Did the response fail to follow the format? These causes require different solutions.
- Prompt and format: request a short, validatable output, provide an input and output example, and check the result schema.
- External data: for policies, documents, and catalogs that change, retrieve the current information from your system and send only relevant excerpts. Also assess access control; a good search with poor permissions can expose data.
- Application flow: break complex tasks into verifiable steps. Use business rules outside the model when they need to be deterministic.
- Model: compare more than one model using the same test suite. A larger model is not automatically better for short classification.
Only consider fine-tuning after testing these options and gathering enough labeled examples. The Hugging Face documentation on fine-tuning explains that it continues the training of a pre-trained model on data for a task or domain; this differs from creating all weights from scratch. Check the model license, data origin, training cost, and evaluation procedure.
Step 4: decide whether you really need your own model
Training a model from scratch requires data collection and cleaning, tokenization, architecture, GPUs, storage, experiments, checkpoints, security, and a team capable of evaluating regressions. Even after training, you need to serve the model with acceptable latency and availability. For many products, this cost is not justified until there is a proven need that APIs or open models cannot meet.
If the requirement is weight control or execution on your infrastructure, compare an already trained open model with your API prototype. Measure quality, throughput, GPU memory, cost per task, and operational effort. The Flatkey GPU Compute area can serve as a starting point for examining infrastructure, but availability, pricing, and configuration should be checked at the time of the decision. Do not calculate savings using a GPU that is always busy when your actual workload has peaks and idle hours.
A hybrid architecture is also possible: predictable tasks on an open model under your control and difficult cases on an external model API. This requires clear routing and observability, not merely two configured endpoints.
Step 5: prepare the application for real-world use
Before releasing to users, conduct a simple review:
- Data and access: which data goes into the prompt? Who can access each document? What goes into logs?
- Quality: evaluate common, rare, and adversarial cases separately; document an acceptable error rate and when to escalate to a person.
- Cost: estimate input and output tokens, calls per task, repeated attempts, and the model's current price. Track cost per useful result.
- Operations: define timeout, limits, backoff for
429, fallback, and a way to disable the feature without affecting the rest of the product. - Changes: test again when changing the model, prompt, documents, SDK, or provider. Version the configuration that generated each result.
An HTTP 200 response does not prove that the product completed the task correctly. For a classifier, compare it with the expected label. For a response based on documents, verify that the citation truly supports the claim. For generated content, request human review at the points of greatest impact.
How much does it cost to build artificial intelligence?
There is no single price. An API-based prototype can start with low traffic, but the cost grows with calls, tokens, more expensive models, tools, and retries. A retrieval-based system adds search, storage, and document maintenance. Fine-tuning and self-hosting add GPUs and operations. Training from scratch expands these requirements even further.
Create a spreadsheet with five variables: active users, tasks per user, calls per task, tokens per call, and retry rate. Multiply by the current price of the chosen model and add storage, search, GPU, and operational work where applicable. Compare alternatives using the same test set and the same definition of a completed task. The Flatkey pricing page is the source for pricing on its route; if you use another provider, consult its page.
Frequently asked questions
Do I need to know how to code to create an AI?
Visual tools can help prototype an idea. To integrate AI into a product with user data, someone needs to handle authentication, secrets, validation, costs, and errors. Knowing how to code or working with a technical team makes these controls verifiable.
What is the difference between creating an AI and training an AI?
Creating an AI application means building a useful workflow around a model. Training means changing a model's parameters with data and compute. A product can be new and valuable without training a model from scratch.
Can I create an AI using only an API?
Yes, for many tasks. The API provides the model's capability, but your application remains responsible for the interface, data, rules, evaluation, and security. If you need up-to-date documents, add a retrieval step instead of assuming the model knows your internal information.
Next step: choose a task, set aside test examples, and make a small call. Only expand the scope when you can measure quality and cost. If the same application needs to test multiple models through one integration, consider the Flatkey chat completions route with the current models and limits of your account.
