AI consulting in Madrid: choose the work you need

You may know that an AI feature needs help without knowing which service to buy. A proposal for a document assistant, an agent platform and an architecture review can all arrive under the same label: AI consulting.

For a team hiring in Madrid, the first useful step is to describe a change you need to see. That gives you something to compare across proposals and a basis for accepting the work.

Choose a deliverable from the current problem

These are alternative starting points. You do not need to buy them together. If the cause is unclear, an investigation can be a paid first phase with its own deliverable.

Buying a document-system review

Consider an internal question answered from an outdated policy when the current policy is available. A useful review needs the question, the available documents and the answer the user received.

The work can inspect what was ingested, which passages were retrieved and what reached the model. Include a question that the available documents cannot answer. You should be able to review how the system handles missing evidence as well as a successful answer.

A RAG consulting engagement can address this problem. Agree on examples from the languages and document types your users actually work with. If both Spanish and English are involved, both belong in the review material.

Buying an integration

Write down the input and intended output before choosing the model. For example, a feature might extract specified fields from a document and send incomplete cases to a person for review. The scope should identify that reviewer, where results are stored and what happens when the provider fails.

For LLM integration, ask to see the agreed behavior in the application that will use it. An isolated API call can help explore feasibility; acceptance should cover the integration, its permissions and the relevant error cases.

When the feature takes actions, decide which actions can run automatically and which need confirmation. Start by drawing a workflow whose actions you can follow and stop. Separate agents can be considered where the work calls for distinct responsibilities.

Location and working arrangements

Pharosyne is based in Madrid and works remotely. Any in-person meetings should be agreed for the individual project. Location alone does not define availability or what an engagement includes.

To prepare the work, explain where your team is based, which language it will use for review and who can provide access to the system. For a distributed team, the remote consulting guide covers review arrangements and handover.

You can inspect the founder's public work through Petru Arakiss's profile and GitHub. Public technical work is useful background; the proposal still needs to explain the work for your system.

What to ask for in a proposal

Look for a named system, a defined outcome and explicit exclusions. Agree who reviews changes, who authorizes deployment and what documentation remains with the team.

Access and data dependencies should be visible. If the client must prepare sample documents before testing can start, put that requirement in the scope. Price and timing should be agreed against the work and those dependencies.

For a commercial website or booking flow, Merki Studio may be relevant. At Pharosyne, I can review an AI system or take responsibility for a defined part of its implementation. Send the current behavior and the change you need so we can identify an appropriate first engagement.