Questions about bringing AI into your organization

KAIONE is an Israeli company that implements AI in organizations. We map how your organization really works, build AI tools that fit that work on the systems you already have, and train people from your own teams to run and improve them. We call them AI champions. After about 12 weeks we measure the result against your starting point and hand everything over in your name. The goal is that you can carry on without us, and we stay available after that.

All three, in the same project. The market has firms that only advise, only train or only build. We set the strategy with you, build tools that actually work, and train your team to run and maintain them. That way the recommendation doesn't stay in a slide deck, and the tool isn't left without anyone who knows how to use it.

Organizations where a lot of time goes into repetitive work that passes between people and systems: reports, comparing quotes, answering requests, onboarding employees or tracking stock. What matters isn't the industry or headcount, but a painful process you can measure and someone in management who wants to change it. If an off-the-shelf tool is enough for you, we'll say so in the first conversation.

Not with the technology, but with the process that weighs on you most. In four mapping sessions with key teams we look at where the time really goes and pick two or three processes against three tests: how much it hurts, whether improvement can be measured, and whether the data it needs is available. That way the first investment goes where it's easy to see whether it worked.

Sometimes that's exactly what you need, and then we'll tell you. A general tool helps you write, summarize and search. When the work depends on your systems, procedures and data, like comparing supplier bids or compliance forms, you need a tool that's connected to them and knows your rules. Often the right answer combines both.

Yes. Not all of your data needs to be in order, only the data the chosen process uses. In the mapping we check what exists, what state it's in and what's missing. If the data for a process is too patchy, we'll say so and recommend starting with a different process, or fixing what's missing first.

There's no single price, because scope varies from one organization to the next. The price depends mainly on the number of processes, how many systems need connecting, the state of the data, your information-security requirements and how many champions we train. After the intro call we send you a first outline and a modular quote, so you can start with one area and decide on the next step once you've seen the measurement.

Mainly usage of the AI models, which depends on the volume of work, plus licenses for tools if any are needed. The accounts are in your name and billed directly to you, so you see exactly what you're paying for. Before building we give you an estimate of the running cost at the expected volume, and it's part of deciding which model to use. There's no monthly subscription to us running in the background.

Before building, we measure the starting point together: how long the process takes, how many errors there are and how much manual work it needs. After about 12 weeks we measure again using exactly the same method and turn the difference into hours and money. It's also worth deciding up front what to do with the time that's freed, otherwise it gets absorbed into routine and never shows up anywhere.

We don't promise savings percentages before we've measured, and you should be wary of anyone who does. What we do commit to is a method: a measured starting point, a repeat measurement using the same method, and a report where what didn't work gets as much space as what did. That way the decision to expand rests on your own numbers, not on promises.

Then that's what the report will say, with an explanation of why and what could change. There's no subscription that commits you to continue. Even then, you keep the process map, the baseline measurement, the tools that were built and what your champions have learned, so your next decision is based on data.

You tell us where the pressure is greatest, which systems you work with and what you've already tried. We ask questions and tell you honestly whether we look like a fit or an off-the-shelf tool will do. After the call we send you a first outline and a modular quote.

A first project usually runs about 12 weeks. In weeks 1–3 we hold the mapping sessions and measure the baseline, in weeks 3–8 we build the tools, and in weeks 6–10 the champions train on them with real tasks. In week 12 we measure against the starting point. The exact scope depends on the number of processes and systems.

A first tool usually works within the first weeks of the build. The result itself is measured after about 12 weeks, against a baseline we measure together before we start building. We only count a result when it's measured the same way the starting point was.

These are four sessions of two to three hours, each with a different team of key people. Together we go through the real work: where time goes, where things get stuck between departments, and what's done by hand again and again. At the end there's a process map, two or three chosen processes, and a measurement of how long they take today.

First, four sessions of two to three hours with the key teams. After that, the champions work with us on tasks from their normal week, so training happens during the work rather than instead of it. Everyone else meets the tools once they already work, through their champions.

A process map and a measured baseline; working tools with code and documentation, in your name; AI champions who can change a tool without calling us; an operations guide for when something breaks; and a before-and-after report, with a recommendation on what to expand and what to stop. All of it stays with you, even if you don't continue with us.

Yes. The lab on this site has demos of tools built with this method, with sample data and tools that really work. The projects page publishes case studies with the starting point, the result and what didn't work. In the intro call you can ask for an example close to your field, and when there's a client in a similar field who agrees, we'll gladly connect you.

We decide that with you before building: which cloud service and which region of the world, who gets access, and which data leaves the organization at all. When the information is sensitive, we can choose a suitable provider and processing location, or not send identifying data at all. The accounts are in your name, so access control stays with you, and where needed we sign an NDA and a data processing agreement.

We work through business accounts, such as the API or Enterprise plans, whose terms say data sent to them isn't used to train the model by default. Before connecting a provider we check its terms with you: whether data is used for training, how long it's kept, and whether it's passed to third parties. That's the key difference between an organizational tool and an employee pasting a document into a free version.

Each tool gets only the permissions its task requires, not general access to your systems. We define who can use the tool and what data it's exposed to, keep a record of its actions, and fit the settings to your information-security procedures. If you have a security team, it approves the architecture before go-live.

Amendment 13 to the Privacy Protection Law, in force since August 2025, raised the sanctions and broadened the definition of personal information. So before building a tool that processes personal information, we map which information passes through it, reduce it to what's actually needed, limit permissions and check every provider's commitments, including on transfers of data abroad. We're not lawyers, and the legal calls are made together with your legal counsel or privacy protection officer.

Israel has no dedicated AI law. What applies in practice is mainly the Privacy Protection Law and the data security regulations, for any personal information a tool processes, along with sector-specific regulation, for example in finance or healthcare. The Privacy Protection Authority has published draft guidance on AI systems, so it makes sense to build to its principles now: transparency, data minimization and vendor checks.

Possibly. The AI Act also applies to organizations outside the EU when a system's output is used inside the EU. The transparency obligations in Article 50, such as telling people they're interacting with an AI system and marking AI-generated content, apply from August 2026. Where it's relevant, we build the disclosure and marking into the tool, and the legal classification is checked with your legal counsel.

It's common, and it usually signals a real need. The risk is that company information gets pasted into personal accounts without any control. The answer isn't just to ban it, but to offer an approved alternative that works better, along with simple rules on what may be uploaded and where. This usage usually comes up in the mapping sessions, and that's a good place to start.

Yes, that's the starting point. We build on the systems already working for you, like Excel, Priority, SAP, monday and the inbox, and don't ask you to replace them. The tool fits into the existing process, so as far as possible people keep working in the screens they know.

Usually through the APIs these systems provide, with a dedicated user that gets only the permissions it needs. Where there's no suitable interface, we work with file exports, a dedicated mailbox or read access to the database, whatever your IT approves. In the mapping we check what's possible in each system before committing to a solution.

There's usually a way. Even an old system produces reports, files or emails, and a tool can work with what it already puts out. Sometimes the connection is more limited, for example read-only or updated once a day, and then we'll tell you up front what that means for the tool.

You don't need a development team: we do the building, and the champions learn to run and change the tools without writing code. From IT we mainly need three things: limited access permissions to the relevant systems, a security sign-off on the architecture, and a contact person available for questions. If you have no in-house IT, we work with the vendor that maintains your systems.

We're not tied to any model vendor. We choose a model by task, cost and security requirements, for example models from OpenAI, Anthropic or Google, and in some cases an open model running in your own environment. Because the accounts are in your name and the tool isn't built around a single vendor, you can switch models when a better or cheaper one comes along.

AI champions are people from your own teams who know the work from the inside and want to improve it. They don't need to be technical. They take part in the mapping, learn to run, fix and improve the tools, and then teach their teams. They're chosen together with their managers, for curiosity and the trust of their team, not by job title.

Training happens on tasks from the champions' own week, not on generic examples. They run the tools, fix them when something doesn't work and change instructions and settings, with us beside them. Before we finish, the champions have made at least two changes to the tools on their own, and then they teach their teams.

Ideally, ownership of each process sits with whoever is responsible for it in the business, such as the procurement or operations manager, with IT as a partner on security and connections. Above them you need someone in management who holds the topic: sets what matters at the start, takes part in choosing the processes and decides what to expand after the measurement. An AI project run purely as a technology project tends to stall, because the real change happens in how the work is done.

Our goal is to take repetitive work off people's plates, like copying between systems, preparing reports and answering the same questions again and again, not to replace people. What to do with the time that's freed is your management decision, and it's worth making in advance: more customers, faster service, or work that has been put off until now.

Worry is a natural reaction, especially when it isn't clear what the tool will change in each person's job. That's why employees take part from the mapping stage, the tools are built around their tasks, and the champions are colleagues from the team rather than outsiders. If you have a workers' committee, it's worth involving it early, before the tools go live.

For everyday use and common changes, no. We build so that changes like updating an instruction, adding a rule or swapping a source document don't require writing code, and the champions practice them during the project. For a deeper change, like connecting a new system, there's full documentation of the code, so any developer can pick up where we left off.

Language models can make mistakes, so we build the tools so that an error is caught before it costs money. The tools answer from your own sources and show where each answer came from. When there's no source, they say they don't have an answer. Actions with consequences, like sending to a customer or updating a system, go through human approval. Before go-live, every tool is tested on real examples from your work.

Technically yes, but we start carefully. At first the tool prepares, summarizes and recommends, and a person approves every action that goes outside or changes data. Once the tool has proven itself on enough cases, we decide together which simple, repetitive actions it will carry out on its own, with limited permissions and a record of every action.

Before building, we agree together on what counts as a correct answer and collect a set of real examples from your work. The tool is tested on them before go-live, and again whenever it's changed or the model is swapped. The results go into the measurement report, together with the cases where the tool got it wrong.

Leading language models now handle Hebrew well in common business tasks such as summarizing, answering questions and extracting information from documents. Quality still varies between models and tasks, so every tool is tested on your real Hebrew examples before go-live. If your people also work in Arabic, English or Russian, we test those languages too.

Models do change fast, which is why we don't build the tool around a single model. The model is a replaceable component, and the test set lets us confirm a new model works at least as well as the old one before switching. So upgrading to a better or cheaper model takes testing, not a rebuild.

Yes. When a decision directly affects a person, such as hiring, dismissal or credit, AI can help prepare the material, but the decision should stay with a person. A process that happens rarely, or where there's no way to measure improvement, is usually not the place to start either. If that's your situation, we'll tell you during the mapping.

You do. The code, prompts, model-provider accounts and data are in your organization's name from day one. If you decide to continue on your own or with another vendor, everything you need is already with you.

We finish when five conditions are met: every tool has a named owner on your side; the champions have made at least two changes to the tools on their own; there's an operations guide explaining what to do when something breaks; you can measure the results yourselves, the same way we did; and the code, prompts, accounts and data are in your name. The end date is agreed with you up front.

Your team runs the tools on its own: every tool has an owner, there's an operations guide, and there are AI champions who have already made changes on their own. When something breaks, you start with the guide and the champions, and because the code and documentation are yours, another developer can handle it too. We stay available for questions, a check-up or a new area, with no monthly subscription running in the background.

That's exactly why we build so you won't depend on us. Everything is documented as we go, the code and accounts are in your name, and your champions know the tools from the inside. Even if we're unavailable on a given day, the tools keep working and there's someone on your side who knows how to handle them.

Yes. The measurement report includes a recommendation on what to expand and what to stop, and if you want to open a new area we use the same method: mapping, building, training and measuring. In the second area your champions already have experience and can take on a bigger share of the work.