8 Generative AI Project Ideas for 2026: Stack, Data and What Interviewers Ask

Most lists of generative AI project ideas hand you a title and leave. Build a chatbot. Build a resume screener. Build a PDF summariser. Then you open a terminal and realise nobody told you which vector store fits in a free tier, which dataset will not get you into trouble, or what an interviewer will press on once you say the word RAG. This guide fixes that. Eight builds, each with the stack, the data source, the hard part, and the question you should expect in the interview.

What Makes a Generative AI Project Idea Worth Building in 2026

Run every idea through four checks before you write a line of code. If it fails any one of them, change the scope rather than the topic.

1. It has a measurable failure mode. You must be able to finish this sentence: "On my 50 test questions, it gets X right." A chatbot that answers plausibly has no number attached to it. A support assistant that answers 41 of 50 questions correctly, and whose nine failures are all about refund policy, has a story.

2. The data is legitimately yours to show. Recruiters will open your repo. Company data you exported cannot go in it. Public datasets, your own documents, and scraped-with-permission public pages can.

3. It runs for under Rs 2,000 a month. If it needs a GPU instance, you will kill it in three weeks and the demo link in your resume will 404 during the interview.

4. You made one decision you can defend for ten minutes. Chunk size, reranking, when to refuse to answer, why Haiku instead of Sonnet. One deep decision beats ten shallow features.

The right-hand column is what the syllabus of a live AI Engineer course is built around: scoping, measuring and shipping rather than prompting. But you can do all of it alone with the stack below.

The Free Stack: What Generative AI Projects Actually Cost to Run

Here is what you can stand up today without a credit card. These limits were checked on 11 September 2026 and providers change them, so re-check before you commit a design to one of them.

Three commands get the local half of that running:

# 1. Vector store, local, no signup
docker run -p 6333:6333 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant

# 2. Python side
pip install qdrant-client sentence-transformers anthropic streamlit duckdb

# 3. A real dataset instead of three PDFs you wrote yourself
pip install kaggle          # then put kaggle.json in ~/.kaggle/
kaggle datasets list -s "customer support tickets"
kaggle datasets download -d owner/dataset-slug -p data --unzip

The kaggle datasets list -s search step matters more than it looks. Picking a dataset that is messy in an interesting way, with duplicates, mixed languages and empty fields, gives you something to talk about. A clean dataset gives you nothing.

Also read: Retrieval Augmented Generation Explained in 2026: How RAG Actually Works, Step by Step if the retrieval half of these projects is still fuzzy.

Generative AI Project Ideas 1 to 3: RAG Builds That Go Past the Chatbot

Why RAG Project Ideas Still Work in 2026

Yes, everyone has built a document chatbot. That is exactly why the bar is so easy to clear: the average submission has no evaluation set, no refusal path, and a chunking function copied from a tutorial. Beat those three things and you are in the top decile of RAG project ideas an interviewer sees that week.

Project 1. Regulation Q and A with a refusal path. Pick a public corpus with real consequences for being wrong: RBI circulars, GST notifications, your university's academic regulations. Index it, then add the part nobody adds: if the top retrieved chunk scores below a threshold you tuned, the system says "I do not have this in my sources" instead of guessing. Stack: Qdrant, sentence-transformers, Claude Haiku, Streamlit. The hard part is choosing the threshold, and defending it is your ten-minute answer.

Project 2. Multilingual product search for an Indian catalogue. Take a public e-commerce dataset and make search work when the query is Hinglish. "sasta bluetooth speaker" should return the same things as "cheap bluetooth speaker". The hard part is that pure vector search quietly fails on exact identifiers like model numbers, so you combine it with keyword search and tune the blend. That hybrid retrieval decision is one of the most common follow-up questions in AI engineering interviews.

Project 3. A codebase explainer for one open-source repo. Index a mid-size repo and answer questions like "where is authentication handled". The hard part is that code chunks badly by character count; you need to split on function and class boundaries instead.

All three live or die on one function. Here is the boring version that outperforms most tutorial code:

def chunk(text, size=900, overlap=150):
    """Fixed-size chunks with overlap. Unglamorous, and hard to beat."""
    out, start = [], 0
    while start < len(text):
        out.append(text[start:start + size])
        start += size - overlap
    return out

Why not split on blank lines, which every tutorial does? Because a bulleted list becomes forty useless twelve-token fragments and a table becomes one four-thousand-token wall, and your retriever now has to choose between noise and indigestible blocks. Fixed size with overlap is predictable. Once it works, try the upgrade: chunk on headings, then sub-chunk anything over your size limit. Measure both on the same 50 questions and keep the winner. That single before-and-after number is the most useful sentence in your README.

Agent Project Ideas 4 to 6: When the Model Has to Take Action

Retrieval projects read. Agent projects act, which means they can be wrong in expensive ways, which is precisely why teams pay for people who have built one carefully.

Project 4. A three-tool support triage agent. Tools: look up order status, check refund eligibility, escalate to a human. The hard rule: the agent may never state a refund decision itself, only report what the eligibility tool returned. Then write 30 adversarial prompts trying to make it break that rule, and report how many got through. Tool design and safe tool boundaries are the core of the CCDV-F developer certification syllabus, and they are what this project demonstrates.

Project 5. A research agent with a hard budget. Give it web search and a strict cap: it must answer within six tool calls and 20,000 tokens, and if it cannot, it must say what it would need. Budget-bounded agents are what production actually looks like, and almost no portfolio has one.

Project 6. A data-quality agent over a real table. Point it at a messy CSV loaded into DuckDB, give it a tool that runs read-only SQL, and have it produce a written data-quality report: null rates, suspicious duplicates, out-of-range values, with the SQL it ran as evidence. If pipeline work is where you want to end up, this is the project that connects neatly to Microsoft Fabric and DP-700 data engineering.

The mechanics are smaller than people expect. A tool is a name, a description and a JSON schema, and the loop is three steps:

tools = [{
    "name": "get_order_status",
    "description": "Look up the current status of a customer order by order ID.",
    "input_schema": {
        "type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"],
    },
}]

msg = client.messages.create(
    model="claude-haiku-4-5-20251001",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "Where is order IN-48192?"}],
)

if msg.stop_reason == "tool_use":
    call = next(b for b in msg.content if b.type == "tool_use")
    result = get_order_status(**call.input)   # your function, your database
    # append the assistant turn, then send a tool_result block back and let it finish

Spend your effort on the description field, not the loop. "Look up the current status of a customer order by order ID" gets called correctly; "order tool" does not. Most agent failures that people blame on the model are really one vague tool description.

2 Generative AI Project Ideas Almost Nobody Builds

Project 7. An evaluation harness. Not a model, a scoreboard. Write 50 questions with expected answers, then a script that runs your RAG system against all 50, scores each one, and prints a table: overall accuracy, accuracy by question type, and the five worst failures with their retrieved chunks attached. Run it before and after every change. When an interviewer asks "how do you know your change helped", you will be one of very few candidates who can answer with a number rather than a feeling. Evaluation, drift and monitoring are also the operational half of the MLOps Engineer course built on AI-300, and the same harness idea shows up in CCAR-F architecture work as the thing that makes a design reviewable.

Project 8. A cost and latency optimiser. Take any of the projects above and make it cheaper without making it worse. Route easy questions to a smaller model, cache repeated context, trim retrieved chunks from eight to four, and publish a table of cost per 1,000 questions against accuracy at each setting. Here is the arithmetic, using rates from the published Claude pricing page:

PRICE = {"haiku-4.5": (1.00, 5.00), "sonnet-4.5": (2.00, 10.00)}  # USD per million tokens

def cost(in_tok, out_tok, model):
    p_in, p_out = PRICE[model]
    return (in_tok / 1_000_000) * p_in + (out_tok / 1_000_000) * p_out

# 5,000 questions a month, 3,000 input tokens each (system + 6 chunks), 400 output
print(round(cost(5000 * 3000, 5000 * 400, "haiku-4.5"), 2))    # 25.0
print(round(cost(5000 * 3000, 5000 * 400, "sonnet-4.5"), 2))   # 50.0

$25 against $50 a month. Now the interesting question, and the one worth a section in your README: does Sonnet answer enough more of your 50 test questions correctly to justify doubling the bill? Sometimes yes, often no, and the candidate who has actually measured it on their own project is memorable. The same pricing page notes that prompt caching can cut the cost of repeated context by up to 90%, which is the single biggest lever in that table because your system prompt and retrieved context repeat on nearly every call.

Worked Example: A Document Q and A Project You Can Finish This Weekend

This is Project 1, end to end, at the level of detail you would actually follow. Budget four to six hours.

Step 1, get real documents (30 min). Download 30 to 60 public PDFs on one narrow topic. Narrow matters: "RBI circulars on digital lending" beats "finance documents", because a narrow corpus lets you write test questions you know the answers to.

Step 2, extract and chunk (45 min). Pull text out with pypdf, run the chunk() function above, and store the source filename and page number alongside every chunk. Skipping that metadata is the mistake you will regret in step 6, because you will have no citations to show.

Step 3, embed and index (45 min). Embed with a sentence-transformers model locally so embedding costs nothing, then upsert into the local Qdrant container from the earlier command. For 50 PDFs you are looking at a few thousand vectors, which is nothing against the 1 GB free tier.

Step 4, write 50 test questions before you build the answering half (60 min). This is the step everyone skips and the step that makes the project. Include ten questions whose answers are genuinely not in your corpus. Those ten are how you test the refusal path.

Step 5, the answer call (45 min). Retrieve the top six chunks, put them in the prompt with their filenames, and instruct the model to answer only from the provided sources and to say so plainly when they do not cover the question.

Step 6, measure, then tune (90 min). Run all 50 questions. Expect something like 33 to 38 correct on the first pass, with the unanswerable ten being where it embarrasses itself by inventing an answer. Now tune in this order, re-running the whole set after each change: raise the refusal threshold, then try top-4 instead of top-6 chunks, then try heading-aware chunking. Record every number.

Step 7, ship it (30 min). A Streamlit front end with the answer, the citations, and a small footer showing tokens used and cost for that query. That cost footer takes fifteen minutes and it is the detail interviewers remember, because it signals you think about production, not demos.

What you can now say out loud: "It went from 34 out of 50 to 43 out of 50. Most of the gain came from the refusal threshold, not the model. Each query costs about 0.4 paise." That is a project.

AI Project Ideas for Beginners: How to Scope a Build You Will Actually Finish

The failure pattern for beginners is not difficulty, it is scope. People pick a project that needs five things to work at once, get two working, and abandon it. The fix is to sequence so that you have something demonstrable at the end of every week.

A realistic three-week schedule for your first build, at roughly ten hours a week:

• Week 1. Data in, chunks out, vectors indexed. Success looks like a script that prints the top three chunks for a typed query. No model call at all yet.
• Week 2. Add the model call, the citations, and the 50-question test set. Success is a printed accuracy number, however bad it is.
• Week 3. Tune, add the refusal path, deploy on Streamlit Community Cloud, write the README around your before-and-after table.

Two rules that save beginners the most time. First, use a local vector store during development and a hosted free tier only for the deployed version, so you never burn quota on debugging runs. Second, cache every embedding to disk on first computation; re-embedding the same corpus forty times is the most common reason a beginner's laptop fan becomes the loudest thing in the house.

If you want structure around this rather than doing it solo, the free webinars are the lowest-friction place to see a build walked through before deciding anything, and the full certifications overview shows which credential each of these project types maps to.

Also read: AI Engineer Roadmap 2026: 7 Steps to Land Your First Role in India for how these projects fit into a full learning sequence.

Mistakes That Make AI Portfolio Projects Fail the Interview

These are the patterns that get AI portfolio projects politely skipped over. Each one is cheap to fix once you can see it.

One more, less obvious: deployment counts. A project that only runs on your laptop is half a project. If cloud deployment and CI are where you feel weakest, that is the territory an AWS Solutions Architect and DevOps program covers, and containerising the app first makes any hosting choice easier.

Also read: Docker Tutorial for Beginners 2026: Containerise a Python API in 7 Steps, which is the fastest way to make any of these projects portable.

What Interviewers Actually Ask About Your Project

Once a project is on your resume, expect the conversation to go here. These are worth rehearsing out loud, because the reasoning is what is being assessed, not the vocabulary.

"How did you pick your chunk size?" The wrong answer is a number. The right answer is a comparison: "I tested 500, 900 and 1,500 characters on the same 50 questions. 900 with 150 overlap was best; 1,500 diluted retrieval because one chunk covered three topics."

"What happens when the answer is not in your documents?" They are testing whether you built a refusal path at all. Describe the threshold and how you tuned it, including the false-refusal cost.

"Why this model?" Answer with cost and accuracy together. "Haiku 4.5 at $1 per million input tokens handled 43 of 50. Sonnet got 45 at double the price, so I kept Haiku and put the savings into more retrieved context."

"How would you take this to 10 million documents?" They want to hear you name the things that break first: batch embedding and its cost, index size against memory, latency of retrieval, and incremental updates instead of full reindexing. That systems-level answer is the same reasoning the CCAR-F architect track assesses, and 360DT practises it live in architecture review sessions rather than as theory.

"Show me where it fails." Have the answer ready. A candidate who opens their worst five failures unprompted is immediately more credible than one who insists it works well. If your build produces dashboards or reporting rather than chat, the same rule applies, and the analytics side of it maps to Power BI and PL-300 work.

Pick one project from this list, give it three weeks, and finish it to the point where you have a number to defend. If you would rather build it alongside people who will review your code and push you past the first plateau, the AI Engineer course runs live on weekends and covers exactly this path from retrieval to agents to evaluation, or you can sit in on a free webinar first and decide after.

Frequently asked questions

About this guide. 360 Digital Transformation is an independent training provider. We are not affiliated with the certification bodies, vendors or open source projects mentioned, and our courses are exam preparation rather than official training. Tools and versions change quickly; commands and figures cited were checked on 11 September 2026.