Most people use AI in their daily life and know how helpful it can be, and wish to use it for their professional tasks, too.
So decision-makers basically have three options with respect to AI use:
Tolerate employees using AI services they are familiar with.
Restrict 1.
Analyze the internal processes and provide controlled AI infrastructure.
Option 1 is undesirable, because every work day, confidential information and intellectual property go where they shouldn’t go („Shadow AI“), and the models and prompts used are totally uncontrollable.
Option 2 (if it can be 100% implemented) solves the Shadow AI issue at the cost of efficiency.
Option 3 fulfills the need for AI based automation, but data protection and standardization of prompts and other process steps are by design.
}}} {{{#!div style="text-align: center; margin-left: 20px; margin-bottom: 40px; width: 350px; height: 60px; border-style: solid; border-width: 5px; background-color: #00cc00; border-color: #00aa00; font-size: 14pt; font-weight: bold; display:inline-block; border-radius: 15px;" {{{#!div style="display: inline-block; padding-left: 0px; " {{{#!html Download the walkthrough PDF }}} }}} }}} {{{#!htmlNo black boxes anymore. You decide:
Which models you use.
Where each of them is hosted (cloud, dedicated hosting, on premise, air-gapped).
Which data you access and where it is stored.
Which processes use which predifined prompts and which models.
Who may use which processes, prompts, data and models.
And power users / builders in your company can build new processes (which can be restricted by permissions.
}}} }}} }}} {{{#!tr valign=top {{{#!td style="border-width: 0 10px 10px 0; border-color: #ffffff; padding: 0 0 0 20px; width: 50%;" [[Image(Public/ImageContainer:Simple_RAG.png, align=left, width=99%, margin-bottom=20, link=)]] }}} {{{#!td style="border-width: 0 10px 10px 0; border-color: #ffffff; padding: 0 0 0 20px; width: 50%; text-align: left;" {{{#!htmlWe'll illustrate this with a simple example everybody knows: Retrieval Augmented Generation (RAG).
While Large Language Models (LLM) have "knowledge" and reasoning from their training data, they do not know about data that were not in the training, like proprietary documentation. Similarly, sparse or ambiguous information in the training data can weaken the results.
For example, if you ask for Ludwig van Beethoven's birth date, you will certainly get a correct result. But if you ask for the birthday of the mayor of the village you live in, in the best case, the LLM states, it does not know. But often, you will get some made up date.
To fix this, before prompting the LLM to answer, RAG processes find and fetch data containing the required information to answer correctly. Then, they inject the data into the prompt. The result is a response based on the information provided.
}}} }}} }}} {{{#!tr valign=top {{{#!td style="border-width: 0 10px 10px 0; border-color: #ffffff; padding: 0 0 0 20px; width: 50%;" [[Image(Public/ImageContainer:Prompt_Editor.png, align=left, width=99%, margin-bottom=20, link=)]] }}} {{{#!td style="border-width: 0 10px 10px 0; border-color: #ffffff; padding: 0 0 0 20px; width: 50%; text-align: left;" {{{#!htmlObviously, for a RAG solution, we need to be able to execute prompts with an LLM. In i2ai, prompts are predefined by builders, skilled users with permission to do so.
Prompts typically have one or more input message fields that are injected into the prompt at the defined location.
The model to be used and the execution parameters are defined by the builder, not the end user.
Thus, instead of end users inventing prompts (or looking them up somewhere) for each task, the task prompts are predefined, standardized and linked to specific models. This approach reduces variance and makes sure the same task is always performed the same way. And since the model is linked to the prompt, builders and not end users decide which data flows where. For example, this prompt uses GPT-OSS 120b running in the cloud of one of the leading hyperscalers. This is fine, because the RAG uses data that's on the public internet anyway.
With confidential data, the same model could be run on the customer's own hardware and end users had no way around it. Local models (with potentially limited capacity of tokens per hour) can therefore coexist with cheaper / less limited hyperscaler based models and the one that makes most sense for a certain application will be used.
From a builder perspective, this is easy to use. Prompts can be cloned, edited and tested right away.
The prompt in this example converts a question the user types in into a query that can be used in Google Search API.
}}} }}} }}} {{{#!tr valign=top {{{#!td style="border-width: 0 10px 10px 0; border-color: #ffffff; padding: 0 0 0 20px; width: 50%;" [[Image(Public/ImageContainer:Trans_Editor.png, align=left, width=99%, margin-bottom=20, link=)]] }}} {{{#!td style="border-width: 0 10px 10px 0; border-color: #ffffff; padding: 0 0 0 20px; width: 50%; text-align: left;" {{{#!htmlTransforms resemble prompts, but are a more generic concept. A transform converts a set of input data into a set of output data. Transform implementations can be to read from an external system or write to it, do some form of calculation or format conversion, or, as in the example shown here, transform a Google search string into a JSON result set (using Google Search API), as part of a RAG application.
The query field is the inbound interface and the outbound interface is the JSON result.
Transforms can be implemented as needed using the standard transform interface; custom transforms behave like standard transforms from an interface perspective, and have configurable custom parameters.
}}} }}} }}} {{{#!tr valign=top {{{#!td style="border-width: 0 10px 10px 0; border-color: #ffffff; padding: 0 0 0 20px; width: 25%;" [[Image(Public/ImageContainer:Process_Editor.png, align=left, width=99%, margin-bottom=20, link=)]] }}} {{{#!td style="border-width: 0 10px 10px 0; border-color: #ffffff; padding: 0 0 0 20px; width: 75%; text-align: left;" {{{#!htmlElementary prompts and transforms can be plugged together using the process editor. A process as a whole has input and output fields and from the outside can be seen as a black box. Inside, a process has a substructure of multiple steps with control structures like branches and loops.
A whole process can be used as one of the functional blocks in a parent process, too, like the fetching and ranking subprocess in this diagram.
Thus, complex, recurring business processes and operations can be reuses wherever needed.
The simple RAG example we've shown here completely works without local storage. It uses data from sources publicly available on the Internet, like Wikipedia, or in this case, the documentation of the DICOM standard for medical imaging.
However, i2store, as part of our platform, provides a fast and AI friendly storage engine.
}}} }}} }}} {{{#!tr valign=top {{{#!td style="border-width: 0 10px 10px 0; border-color: #ffffff; padding: 0 0 0 20px; width: 25%;" [[Image(Public/ImageContainer:Filter.png, align=left, width=99%, margin-bottom=20, link=)]] }}} {{{#!td style="border-width: 0 10px 10px 0; border-color: #ffffff; padding: 0 0 0 20px; width: 75%; text-align: left;" {{{#!htmlUsing public data as shown before is relevant for many applications, but often data to be used as background information for RAG and other processes is proprietary.
If such data is accessible somewhere in an information system in the network, it can be made accessible using a transform using the system's API. In this case, it can use the filtering and searching functions exposed by the API.
However, i2store, the storage engine that's part of our system, allows you to store such data locally:
Local data can be searched, filtered and ranked using the full four axes indexing in i2store.
Local content can be searched and ranked by:
Full text
Typed metadata supporting taxonomies
Typed relations with searchable metadata
Vector based similarity
All axes can be queried simultaneously in one single expression.
Holding the data locally becomes relevant when external information systems are unavailable. This is particularly important for air-gapped systems in high security environments (e. g., on-board defense applications).
Data is organized in so-called nodes. A node represents one bit of information, like a DITA topic, a markdown file, a PDF or an image.
For various requirements, nodes can have different, coexisting representations. For example, a PDF is stored as the unmodified binary file in the first place. For full-text search, the textual content is automatically extracted and stored in a separate field. Next, the full-text content is vectorized using an embedding model, enabling vector-based similarity ranking. A node can also have a preview HTML representation. Apart from this, renditions can be appended, like a low resolution JPG that was rendered from a TIFF source.
Every node belongs to exactly one domain. Domains are information packages with common permissions. There is no "default" granularity for domains, they can be defined as needed by the application(s).
i2store allows definition of typed attribute fields. Such fields can be numeric, textual, date, and they can use hierarchical values from taxonomies. Attribute fields can be linked to domains and the nodes in that domain have these attribute fields then. Attribute fields can then be searched using the search API.
i2store provides typed relations that make a link between two nodes. They could have any kind of semantic meaning, like linking up children of a DITAmap, representing a "see also" relation or any other. Relations can have attributes available for filtering, too.
}}} }}} }}} }}} {{{#!htmlThe i2ai / i2store API is not wired on top of the web application, but i2ai / i2store IS the API and all that's behind it. The web application just accepts user interaction and displays results. Therefore, anything you can do in the web application can be called with a few lines of code from any application you want to integrate to:
We explained a simple RAG example on this page. The user interface is just an input field and an output field for result and one for the references. Call the API endpoint with the id of the process and the same input string from the user and get the same results. You can integrate this into any web or desktop application or backend process you like, for example, to implement RAG in your Content Delivery Portal.
Talking about Content Delivery Portals: i2ai / i2store API has all the building blocks for a CDP. It stores content, assigns user permissions, exposes four-axes search and ranking, manages renditions and relations and fetches content on demand. No logic needs to be implemented, just a web frontend matching your corporate design.
With one API service in your network, you can make sure that the same function, wherever you use it, is identical. For example, you might have a process verifying adherence to authoring guidelines in a DITA topic. This function would make sense both in an editor context while the author is writing and as a precondition when lifecycle state is about to be changed to approved. With i2ai / i2store, you can call the identical function in both places, with a few lines of code each.
The API does not depend on how many users are logged into your applications. You can have multiple web frontend instances, but they don't overload your AI infrastructure with numerous, simultaneous requests. i2ai / i2store API manages a job queue with detailed configuration options whether and how jobs of the same type can run concurrently.
i2ai / i2store is your scalable platform for integration of AI, data and services of any kind, with applications of any kind. And you have full control.
Data is stored inside i2ai / i2store or in their native information systems. You know and you control where this is. It can be somewhere in the cloud, or it can be air gapped on the local machine. Or anywhere in between, as the application requires. You don't need to expose data by Model Context Protocol and trust the AI vendor (even though you can), but your process builders decide and define where data gets sent.
The same is true for AI models. For processing of data that's not highly confidential (like maintenance manuals that are publicly available or widely distributed), cheap and fast cloud models can be used. But you can also run models on a rented server in a defined location or even on a local, air-gapped machine.
Prompts and processes are not black boxes, but they can be explicitly edited by your power users. Processes are visualized as a diagram.
Everything users do is subject to detailed, group- or user-based permissions.